M-Audio Transit USB soundcard and Linux
This is a reasonably nice and cheap 24 bit soundcard. It will go
up to 96000Hz on play or record (but not both togetehr) and
up to 48000
Hz for duplex mode. It has internal support for 24 bit and 16
bit audio. The specs of the card are essentially identical at 24
bit and 16 bit, so there seems no advantage in operating in 24
bit mode (see end of this page) However, Linux and this card do not exist together
very well.
It only has a line input, which has a sensitivity of .7V peak to
peak for full scale recording (ie anything greater than .7 V will clip
if the recording level is set to maximum. If the recording level
lower, it will take a higher level input to clip. I do not know what
the maximum input level is. It seems to have a 10K ohm input
impedance but I am not sure of this.
This card 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.
Firmware
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.
- Get the file ma006100.bin from the Windows driver
installation zip file. You can run the Windows
installation file in wine on Linux and it will unpack
that file. One of the unpacked files is a file called (on mine)
Ma006100.BIN. Copy that file somewhere and rename it as
ma006100.bin
Alterntively if you have windows running, get the
file from Windows/system32/drivers/ directory.
- Get the file from the sourceforge project
http://usb-midi-fw.sourceforge.net/
and untar it (tar -xzf madfu-firmware-0.9.tar.gz)
- Copy the file ma006100.bin to the directory
madfu-firmware-0.9
Kernel Version
For kernels ealier than 2.6.8.1 the usb bus reset code had
a severe bug, in that the reset used in the madfuload would
make the system completely unstable and lead to an eventual
kernel crash. This seems to have been fixed in the later
kernels. For later kernels, you should just be able to use
Laditsh's script to install the programs (make install) and
hotplugging should work.
For ealier Kernels
- Edit the file madfuload.c and comment out the lines
if (usb_reset() == -1)
fatal("cannot reset device - %s", strerror(errno));
close(device);
Change them to
/*
if (usb_reset() == -1)
fatal("cannot reset device - %s", strerror(errno));
close(device);
*/
Now compile this program.
./configure
make
- Edit maudio_dfu. This is teh hotplug script which the
usb hotplug process runs when it finds the transit plugged
into the usb bus.
Change the FIRMWAREDIR to whereever you plan to
place the ma006100.bin file.
Change the LOADER to whereever you want to put the
loader file madfuloader.
At the end of the file place the lines.
$LOGGER -t $0 "Resetting the USB bus"
/usr/bin/at now + 1 minutes << EOF
service usb restart
sleep 10
alsactl restore
EOF
- In Mandrake 9.1, edit the file /etc/init.d/usb and remove the # mark in front
of the usb_stop line
stop)
# usb_stop
rm -f /var/lock/subsys/usb
;;
stop)
usb_stop
rm -f /var/lock/subsys/usb
;;
Note that you must make sure that when you issue a
service usb stop
it actually removes the usbcore module. (In the script shipped
with Mandrake this did nothing.)
- Explanation-- the usb-reset() in madfuloader will, if left
in,
crash the system making it very unstable and unuseable. This is
be due to some bug in the USB subsytem on Linuxi for kernels before
2.6.8.
However, the Linux USB system will not recognise the card,
which now is a new card with the firmware loaded without bringing
down the usb bus.
However in the hotplug script, when the usb bus comes down,
the hotplug program is killed at the same time. This means that
if you try to directly run "service usb restart" from the hotplug
script it will die when usbcore is removed, and the script will
never finish to bring it up again. This is why this program is
run from an "at" script which will not die when the usb bus dies.
- You must now copy the hotplug script maudio_dfu into
/etc/hotplug/usb. You must also get the contents of the file
maudio.usermap into the file /etc/hotplug/usb.usermap or into the
file /etc/hotplug/usb.usermap.local. For the former, you can
either copy it in by hand, or you can copy the maudio.usermap to
/usr/lib/hotplug/madfu/usb.usermap and then run update-usb.usermap
Your system should now be able to use the audio card.
Plug it into the usb bus. It will take about one minute befor,
when you run lsusb you will see
0763:2006 M-Audio Transit
as one of the items.
Note that I have no idea what bringing down and then up again
the usb bus will do to the other usb items attached to the usb
bus.
the file
Alsa
I have only run this using Alsa 1.0.1 and the suggestions below
will be limited to that case.
- Get the alsa-drivers tar file and untar it and go into
the top of that directory tree.
Edit the file ./alsa-kernel/usb/usbaudio.c
Change the lines
if (fmt[3] == USB_FORMAT_TYPE_III) {
/* FIXME: the format type is really
* IECxxx
* but we give normal PCM
* format to get the
* existing
* apps working...
*/
pcm_format = SNDRV_PCM_FORMAT_S16_LE;
To
if (fmt[3] == USB_FORMAT_TYPE_III) {
/* FIXME: the format type is really
* IECxxx
* but we give normal PCM
* format to get the
* existing
* apps working...
*/
pcm_format = SNDRV_PCM_FORMAT_FLOAT64_BE;
Note that this format cannot handle the FLOAT64, and if any
program asks the soundcard to handle it, it will claim it can.
It would be nice if there were an "UNKNOWN" format I could use.
However leaving the program as it was completely confuses the 16
bit handling of the driver. It will try to use this Type III
format, but cannot, and that means that 16 bit audio does not work.
- NOw compile and install alsa following the usual
instructions. You will either have to reboot or do depmod to get
the module dependencies. snd-usb-audio should load,
and you should now have a working M-Audio Transit sound card.
Problems
There are still problems.
- The taking down and bringing back up of the usb bus
would be expected to wreak havoc with any other devices
attached to the usb ports on the system. for example if
you were printing on a usb printer when the bs came down
you might mess up the print job.
- The mixer controls are non-standard. While the
alsamixer works, neither aumix not kmix work properly.
There are only two mixer controls-- playback volume and
microphone volume. (together with muting )The playback
slider works, but the microphone slider does ot work. It
stays pegged at 100% (even if alsamixer says the
mocrophone is not at 100%)
Later Kernels and udev
Mandrake/Mandriva since about 10.0 have used udev and hotplug is
deprecated. I have now installed the loader into the Mandriva 2006 system.
Get the latest madfuloader -- currently (Feb 06) at 1.0.9 from SourcForge usb-midi-fw
project and follow the instructions above re comilation. There is no
need to edit any of the files.
Copy the file maudio_dfu into /etc/udev/agents.d/usb/ directory and make it
read/execute for everyone.
Now edit the file /etc/udev/rules.d/70-hotplug_map.rules
and add the two lines to the end of that file
SUBSYSTEM=="usb",SYSFS{idProduct}=="2806",SYSFS{idVendor}=="0763",RUN+="/etc/udev/agents.d/usb/maudio_dfu"
SUBSYSTEM=="usb",SYSFS{idProduct}=="2006",SYSFS{idVendor}=="0763",RUN+="/sbin/modprobe snd_usb_audio"
Then restart the udev subsystem
service udev restart
The first line will load the firmware onto the card, changing its product
id from 2806 to 2006. This will trigger the second line which will load the
snd_usb_audio module, which will create the various alsa sound devices in
/dev/sound, and
if you have the snd_pcm_oss module loaded, the /dev/dsp and /dev/mixer devices.
Transit Performance.
This card is not too bad as a 16 bit card. Using the testing
routine xsndtest
I get the following results. The card's performance is essentially
independent of the playback volume as set in alsamixer. This is good
as it indicates very low playback distortion-- all the noise seems to
be noise perhaps in the recording circuit. For recording however the card
works best with the recording slider about half way up in the
alsamixer. Any more or less and the noise figures rise (by less than a
dB).
This is a test with the full spectrum pink noise. This is a much
more stringent test than the usual harmonic and IM distortion, and it
mimics the spectrum of a real music much more accurately. Note that the
response is very flat with plus or minus about .05dB from 16Hz to
16KHz. There is a slight imbalance of about 0.1dB between the two
channels-- a completely inaudible amount.
These responses were all measured with the output being fed back into
the input, so it is difficult to disentagle the output from the input
performance.
The noise level, except at the lowest frequencies below about 50Hz is
at the one bit level for a 16 bit encoding.(ie the distortion and noise correspond to a level
where on average the lowest bit of the output is distortion and noise) Note
that the digitisation noise for this signal is about another 10dB
lower all across teh spectrum for the 16 bit encoding.
16 bit response
The 24 bit response (feeding the 24 bit pink noise signal out and
recording it using aplay in the -D hw:1 mode, and where the 24 bit
signal is genuine 24 bits with the digitisation noise now down by
another 35dB, and arecord ) is essentially identical to the 16 bit signal.
There is no advantage to using this card in the 24 bit mode. It is a
very good 16 bit card. It is not a great 24 bit card. (Mind you this is
the only 24 bit card I have tested so I do not know if others do better)
24 bit response