UDEV problem with madfu-firmware for M-Audio Transit USB audio interface under Feisty

[hectorC]

I'm trying to get a M-Audio Transit USB audio interface to work with Ubuntu
Feisty. I downloaded, built and installed the madfu firmware loader
from the sourceforge site. When I plug the device it seems that for
some reason the madfuload app can't find the device and fails to load
the firmware. Manually executing the same command found in
42-madfuload.rules in a terminal succeeds at loading the firmware and
the device becomes usable. This is what I get in /var/log/syslog:

Apr 3 12:25:14 hector-laptop kernel: [ 273.803000] usb 1-2: new full
speed USB device using uhci_hcd and address 2
Apr 3 12:25:14 hector-laptop kernel: [ 273.952000] usb 1-2:
configuration #1 chosen from 1 choice
Apr 3 12:25:14 hector-laptop madfuload: cannot open
/proc/bus/usb/001/002: No such file or directory

And actually /proc/bus/usb/001/002 is there but somehow madfuload
can't see it (is it maybe being created after calling the script?).
Executing this command in a terminal works fine: sudo
/usr/local/sbin/madfuload -3 -f
/usr/local/share/usb/maudio/ma006100.bin -D /proc/bus/usb/001/002 and
the Transit becomes visible for alsa and jack. Also It can be activated by
doing sudo /etc/init.d/udev restart with the device plugged.

I found some other users complaining about simillar udev problems
with other devices since Edgy: http://ubuntuforums.org/showthread.php?t=260379
Same computer and same interface using same madfu-firmware works fine under Fedora Core 6.

[Strider (chris-vansteenlandt)]

Experiencing exactly the same problem with m audio transit & ubuntu 7.10.
 Hope this bugs becomes more important. It is getting really annoying having to code each time the madfuload on the command line.
Also ubuntu 7.10 de-activates /proc/bus/usb by default. This was reported in Bug #156085. Al soft should support /dev/bus/usb. Support for /proc/bus/usb devices has been dropped but can be re-enabled by removing the comments from some lines in /etc/init.d/mountdevsubfs.sh. I did this but as described by hectorC I still have the other problem.

[Juhani Simola (ojs)]

I have the same problem with M-Audio Transit and Feisty, too.
When I look what happens when I plug in the sound card using udevmonitor --environment, I see the following:

UDEV [1202071924.118493] add /devices/pci0000:00/0000:00:1d.1/usb4/4-1/4-1:1.0 (usb)
UDEV_LOG=3
ACTION=add
DEVPATH=/devices/pci0000:00/0000:00:1d.1/usb4/4-1/4-1:1.0
SUBSYSTEM=usb
SEQNUM=5752
DEVTYPE=usb_interface
PHYSDEVBUS=usb
DEVICE=/proc/bus/usb/004/016
PRODUCT=763/2806/100
TYPE=254/1/0
INTERFACE=254/1/0
MODALIAS=usb:v0763p2806d0100dcFEdsc01dp00icFEisc01ip00
UDEVD_EVENT=1

Notice that the DEVICE environment variable points at old /proc/bus/usb location instead of /dev/bus/usb where the device actually is. The firmware loader gets the device file from DEVICE environment variable.

[Juhani Simola (ojs)]

Sorry, that problem was with Gutsy. Other problems, similar to the ones reported by hectorC started with Feisty for me, too.

[Strider (chris-vansteenlandt)]

Juhani (I suppose that is your first name :-),

I finally fixed the problem by doing the following :

1) I enabled the /dev/bus/usb support (I commented the necessary lines
in /etc/init.d/mountdevsubfs.sh)
2) The trick is in the /etc/udev/rules.d/42-madfuload.rules file :
    The line that contains the "ma006100.bin" (which should be called
when you plug in the transit) you should put :
ACTION=="add", SUBSYSTEM=="usb", ENV{PRODUCT}=="763/2806/*",
RUN+="/usr/local/sbin/madfuload -l -3 -f
/usr/local/share/usb/maudio/ma006100.bin -D $env{DEVNAME}"

Note that, compared to the original line, I changed two things :
- the condition DEVPATH=="/*.0" is removed : this makes sure the bin
executable is called when all env variables are know.
- the ma006100.bin executable is called with the option -D
$ENV{DEVNAME}. The reason for this is, when you call the bin executable
without an option, it assumes to use the device as specified in the
$DEVICE environment variable (/proc/bus/usb/004/016 in your case) but
for some strange reason Gutsy does not know this environment variable at
startup time (but does now it when you plug in the transit and have
udevmonitor running). Using the DEVNAME variable solves this problem.

Hope this works out for you ...

[Juhani Simola (ojs)]

Hi Strider.

What exactly did you comment out from /etc/init.d/mountdevsubfs.sh?

I did the same modification to /etc/udev/rules/42-madfuload.rules myself but madfuload complains that the device file does not exist. For some reason that I do not entirely understand, adding usleep(10000) to madfuload before opening the device file makes it work. This is a dual core system so maybe there is some timing problem between creating the device node and spawning madfuload.

The DEVICE environment variable is not set by udev but something else. What could that be?

[ttoine (ttoine)]

Please have a look at this bug :
https://bugs.launchpad.net/ubuntu/+source/alsa-tools/+bug/189104

Work is done by the Ubuntu Studio team on the alsa-firmware and alsa-firmware-loader packages. So check if we can consider this current bug as a duplicate of the bug I suggest, and then work all together.

Toine

[Strider (chris-vansteenlandt)]

Juhani,

look for the following lines in mountdevsubfs.sh :

    #
    # Magic to make /proc/bus/usb work
    #
    #mkdir -p /dev/bus/usb/.usbfs
    #domount usbfs "" /dev/bus/usb/.usbfs
-obusmode=0700,devmode=0600,listmode=0644
    #ln -s .usbfs/devices /dev/bus/usb/devices
    #mount --rbind /dev/bus/usb /proc/bus/usb

The last 4 lines should be uncommented to make /proc/bus/usb appear.
Since this did not turn out for me to work, I back commented out these 4
lines.

Toine,
I do not use alsa-firmware-loader. In fact the package is not installed.
But even without the package and some tweaking with udev rules (as
described in a thread I found on ubuntu forums) I made it work for me.
My question now is : I have no problem to solve this issue by a 'more
civilized solution' in this case the alsa firmware loader. But all I can
see in the details of the package is that it's meant for a bunch of
specific soundcards and ... not for the m-audio transit ! So my question
is first of all : how to add a firmware for this soundcard. After that,
we can come to the bug you mentioned being the location of where the
firmware is installed ...
My first guess is that these bugs have nothing to do with each other,
but I might be wrong :-)

[Juhani Simola (ojs)]

Hi.

The issue with udev rules is a known issue in upstream madfuload. A patch was submitted more than year ago but not yet in release: http://sourceforge.net/tracker/index.php?func=detail&aid=1622573&group_id=87777&atid=584353 I guess that an Ubuntu-specific patch could be done if the M-Audio firmwares were in alsa-firmware-loader.

About the timing issue: I did experiments with a simple "firmware loader" that simply attempts to open the device file, sleeps for 0.01 seconds and attempts to open it again. The first attempt fails with ENOENT, second succeeds. This feels like a problem in udev to me.

Juhani

[Greg Grossmeier (greg.grossmeier)]

Thank you for taking the time to report this bug and helping to make Ubuntu better.

The issue that you reported is one that should be reproducible with the live environment of the Desktop CD of the development release - Hardy Heron. It would help us greatly if you could test with it so we can work on getting it fixed in the next release of Ubuntu. You can find out more about the development release at http://www.ubuntu.com/testing/ . Thanks again and we appreciate your help.

[Tim McGee (jarz)]

I can confirm that an M-Audio Transit won't work in Hardy Heron installing madfuload with instructions provided at http://ubuntuforums.org/showthread.php?t=466667 .

I also have made the changes described in this thread, but still have not had any luck. Any time I trigger udev to rescan, PulseAudio duplicates my on-board sound.

[Scott James Remnant (Canonical) (canonical-scott)]

Your firmware loader needs to be changed to use /dev/bus/usb instead. The udev rules will almost certainly also need to be changed to hook on SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device" to avoid races.

[Juhani Simola (ojs)]

For me the problem is that the firmware loader can not open the device without the strange wait. No path problems after the patch. I have ACTION=="add", SUBSYSTEM=="usb", ENV{PRODUCT}=="763/2806/*", ENV{DEVTYPE}=="usb_device" in udev rules.

[Nobre (nobre-it)]

I really am convinced about this problem with idvendor and idproduct at powering Ozone and the UDEV.
When the OS identifies as ID 0763:2808 Midiman, I can't get Ozone working.

But if the OS get ID 0763:2008 Midiman... great... it works! so, the madfuload driver could be running only if this ID's is correct!

Im trying to discover how could I test an IF or ELSE code in the/etc/udev/rules.d/42-madfuload.rules file, to load the driver using one of this two IDs...

IM USING HARDY HERON

[Scott James Remnant (Canonical) (canonical-scott)]

Could someone please summarise this for me?

I can make no sense of the above discussion, and have absolutely no idea what problem people are having, and what steps people have attempted to take to solve it (and whether they worked or not).

[Juhani Simola (ojs)]

As far as I can tell, there are at least three different problems mashed together in this thread.

The first one is that the upstream M-audio firmware loader tries use the old /proc/bus/usb interface. There is already a patch at http://sourceforge.net/tracker/index.php?func=detail&aid=1622573&group_id=87777&atid=584353. It can also be fixed by linking /dev/bus/usb to /proc/bus/usb but I do not think this is a good idea. The solution I'd prefer would be integrating a patched version of madfuload to alsa-firmware-loaders or making a separate package for the patched drivers.

The second problem is that there is some timing issue that prevents the firmware loader from opening the device file at the moment udev starts the loader. After a short wait the device is openable. I have not yet had time to check if this is still an issue in Hardy. The people complaining at http://ubuntuforums.org/showthread.php?t=260379 may have the same problem.

I checked the source of udev. From there it seems quite clear that the device files are created well before the program specified by the RUN part of udev rule is started. Could it be that creating the device is not atomic and therefore control returns to udev before the device is fully usable?

The third one may have something to do with different device IDs but I am not really sure what Nobre is saying. It might have to do something with the fact that M-Audio devices change their device ID after the firmware has been loaded. For example, my Transit is shown as 0763:2806 when it is first plugged in. This device can not do anything but receive firmware. After the firmware has been loaded, the Transit disconnects and reconnects as 0763:2006 which is an USB audio device and does not need any special drivers any more. So, you need to load firmware only for 2806 (or 2808 for the Ozone).

More about the timing issue: Attached is a small program which attempts to open the newly added device, waits for a short time and attempts the opening again. I call it from following udev rule:
ACTION=="add", SUBSYSTEM=="usb", ENV{PRODUCT}=="763/2806/*", ENV{DEVTYPE}=="usb_device", RUN+="/home/ojs/bug/udev/justopen $env{DEVNAME}"

On my system, the Transit gives following output:
Apr 25 23:12:17 eris justopen.c: Opening /dev/4-1 failed: No such file or directory
Apr 25 23:12:17 eris justopen.c: Statting /dev/4-1 OK
Apr 25 23:12:17 eris justopen.c: Delay!
Apr 25 23:12:17 eris justopen.c: Opening /dev/4-1 OK
Apr 25 23:12:17 eris justopen.c: Statting /dev/4-1 OK

I tried the same program with a Bluetooth adapter. The output is interesting:
Apr 25 23:17:06 eris justopen.c: Opening /dev/3-2 failed: No such file or directory
Apr 25 23:17:06 eris justopen.c: Statting /dev/3-2 OK
Apr 25 23:17:06 eris hcid[5477]: HCI dev 0 registered
Apr 25 23:17:06 eris justopen.c: Delay!
Apr 25 23:17:06 eris justopen.c: Opening /dev/3-2 OK
Apr 25 23:17:06 eris justopen.c: Statting /dev/3-2 OK
Looks like the HCI device is registered just after the device has become usable.

[Juhani Simola (ojs)]

I upgraded to Hardy. The timing problem with udev seems to be fixed now.

[Connor Imes (ckimes)]

This bug report is being closed due to your last comment regarding this being fixed with an update. For future reference you can manage the status of your own bugs by clicking on the current status in the yellow line and then choosing a new status in the revealed drop down box. You can learn more about bug statuses at [WWW] https://wiki.ubuntu.com/Bugs/Status . Thank you again for taking the time to report this bug and helping to make Ubuntu better. Feel free to submit any future bugs you may find.

[agorka (oleg-3630)]

M-Audio Transit USB still doesn't work out of the box in Jaunty. I have the same problem:
Feb 17 15:42:17 wind madfuload: cannot open /proc/bus/usb/002/002: No such file or directory

Should I expect this problem to be fixed in official Ubuntu repositories or do I have to hack each Ubuntu I want to plug this soundcard to?

[agorka (oleg-3630)]

I am able to make the Transit soundcard to work by writing
sudo madfuload -3 -f /usr/share/usb/maudio/006100.bin -D /dev/bus/usb/002/002
Can this change (from /proc/bus/usb to /dev/bus/usb) included to the package of madfuload (or some other)? I'm experiencing this bug for a half of year and still nothing changed, it still tries to open /proc/bus/usb.

[Scott James Remnant (Canonical) (canonical-scott)]

Please don't reopen bugs for new ones.

And if your firmware tool is using /proc/bus/usb - that is a bug with your firmware tool.

[agorka (oleg-3630)]

Sorry.
I opened another one, it's here for those who care:

https://bugs.launchpad.net/ubuntu/+source/madfuload/+bug/330573