This card [M-Audio Transit] needs to have firmware downloaded to the card on the USB bus to work. It uses a non-standard "DFU" method which seems to have some problems with Linux. It also mixes its Type I and Type III endpoints to confuse the software. I have found (with the help of and software written by Clement Ladisch and Takashi Iwai.) a way to make this card useable.
The card requires firmware to be downloaded to the card first for it to work as a soundcard. While it appears on the usb bus with Vendor/ProductID of 0763/2806 this is a very primative usb device that does nothing except wait for firmware.
A firmware loader for M-Audio audio devices is available at http://usb-midi-fw.sourceforge.net/.
Interestingly enough, the set-up procedure involves copying the firmware bin file from the Windows driver installation, which is subsequently used by the firmware loader.
Anyways, TFA makes some interesting points:
Unrestricted redistribution of firmware files is satisfactory for some open source operating system projects like OpenBSD, FreeBSD, and many varieties of GNU/Linux, but others like Fedora Core and Debian demand an entirely free software environment, so redistribution of the firmware without the ability to modify and distribute the source code is prohibited.
The firmware, although its being loaded to the device, is still firmware. Do distributions that demand an entirely free sofware environment ship drivers for devices with proprietary firmware? Of course they do. I'm not convinced that this should be any different.
I think that Theo de Raadt, of OpenBSD, has it right:
So instead of lobbying for documentation to write open source firmware, de Raadt would prefer to simply have the right to freely distribute necessary proprietary firmware files with his operating system, along with correct firmware interface documentation so that a driver can be created, and information from the manufacturer regarding bug workarounds.
I don't agree with you here. I completely understand where you are coming from, and I like your Photoshop example, but this isn't the case for me.
If there is one thing that I want to get away from, it is databases (we have enough of them here). I want to work quickly and directly with the data. I stress here that I am not doing any sort of calculations. What I need to do is manipulate the way that the data is presented (a WYSIWYG thing) so that I can then use this data somewhere else. I am doing things that are very well suited for a spreadsheet, a very different thing from authoring a book in Photoshop.
Of course a custom program will work, and this is typically my approach, but they all end up being used once and are thus a large waste of time.
I definitely agree here. I can't tell you how many times I've had to resort to an unneeded amount of hoop-jumping to do some work with a large spreadsheet. I work at a cellular company (RF engineering) and I frequently need to work with extremely large amounts of data (for example, data collected in the field can have millions upon millions of rows). There are work-arounds, but they typically result in me having to whip up a program in C that I will use only once. In a spreadsheet program, the same thing would take me much less time because I am doing something that really should be done with a spreadsheet application.
I've always wondered why this limit exists. If anyone can enlighten me about the technical reasons, that would be much appreciated.
Slashdot Mirror
From http://www.theory.physics.ubc.ca/transit.html:
This card [M-Audio Transit] needs to have firmware downloaded to the card on the USB bus to work. It uses a non-standard "DFU" method which seems to have some problems with Linux. It also mixes its Type I and Type III endpoints to confuse the software. I have found (with the help of and software written by Clement Ladisch and Takashi Iwai.) a way to make this card useable.The card requires firmware to be downloaded to the card first for it to work as a soundcard. While it appears on the usb bus with Vendor/ProductID of 0763/2806 this is a very primative usb device that does nothing except wait for firmware.
A firmware loader for M-Audio audio devices is available at http://usb-midi-fw.sourceforge.net/. Interestingly enough, the set-up procedure involves copying the firmware bin file from the Windows driver installation, which is subsequently used by the firmware loader.
Anyways, TFA makes some interesting points:
Unrestricted redistribution of firmware files is satisfactory for some open source operating system projects like OpenBSD, FreeBSD, and many varieties of GNU/Linux, but others like Fedora Core and Debian demand an entirely free software environment, so redistribution of the firmware without the ability to modify and distribute the source code is prohibited.The firmware, although its being loaded to the device, is still firmware. Do distributions that demand an entirely free sofware environment ship drivers for devices with proprietary firmware? Of course they do. I'm not convinced that this should be any different.
I think that Theo de Raadt, of OpenBSD, has it right:
So instead of lobbying for documentation to write open source firmware, de Raadt would prefer to simply have the right to freely distribute necessary proprietary firmware files with his operating system, along with correct firmware interface documentation so that a driver can be created, and information from the manufacturer regarding bug workarounds.-azzurro
Is Grammar Important to You?
If there is one thing that I want to get away from, it is databases (we have enough of them here). I want to work quickly and directly with the data. I stress here that I am not doing any sort of calculations. What I need to do is manipulate the way that the data is presented (a WYSIWYG thing) so that I can then use this data somewhere else. I am doing things that are very well suited for a spreadsheet, a very different thing from authoring a book in Photoshop.
Of course a custom program will work, and this is typically my approach, but they all end up being used once and are thus a large waste of time.
I definitely agree here. I can't tell you how many times I've had to resort to an unneeded amount of hoop-jumping to do some work with a large spreadsheet. I work at a cellular company (RF engineering) and I frequently need to work with extremely large amounts of data (for example, data collected in the field can have millions upon millions of rows). There are work-arounds, but they typically result in me having to whip up a program in C that I will use only once. In a spreadsheet program, the same thing would take me much less time because I am doing something that really should be done with a spreadsheet application.
I've always wondered why this limit exists. If anyone can enlighten me about the technical reasons, that would be much appreciated.