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
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
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.
** Changed in: udev (Ubuntu)
Status: Confirmed = Fix Released
--
UDEV problem with madfu-firmware for M-Audio Transit USB audio interface under
Feisty
Sorry.
I opened another one, it's here for those who care:
https://bugs.launchpad.net/ubuntu/+source/madfuload/+bug/330573
--
UDEV problem with madfu-firmware for M-Audio Transit USB audio interface under
Feisty
https://bugs.launchpad.net/bugs/102631
You received this bug notification because
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
I upgraded to Hardy. The timing problem with udev seems to be fixed now.
--
UDEV problem with madfu-firmware for M-Audio Transit USB audio interface under
Feisty
https://bugs.launchpad.net/bugs/102631
You received this bug notification because you are a member of Ubuntu
Bugs, which is
** Changed in: udev (Ubuntu)
Assignee: Nobre (nobre-it) = (unassigned)
--
UDEV problem with madfu-firmware for M-Audio Transit USB audio interface under
Feisty
https://bugs.launchpad.net/bugs/102631
You received this bug notification because you are a member of Ubuntu
Bugs, which is
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
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).
** Changed in: udev (Ubuntu)
Status: Confirmed =
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
** Changed in: udev (Ubuntu)
Assignee: (unassigned) = Nobre (nobre-it)
Status: Won't Fix = Confirmed
--
UDEV problem with madfu-firmware for M-Audio Transit USB audio interface under
Feisty
https://bugs.launchpad.net/bugs/102631
You received this bug notification because you are a
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.
--
UDEV problem with madfu-firmware for M-Audio Transit USB
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.
** Changed in: udev (Ubuntu)
Status: Incomplete = Won't Fix
--
UDEV problem with
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
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=47 .
I also have made the changes described in this thread, but still have
not had any luck. Any time I trigger udev to rescan,
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
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=detailaid=1622573group_id=8atid=584353
I guess that an Ubuntu-specific patch could be done if the M-Audio
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(1) to
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/pci:00/:00:1d.1/usb4/4-1/4-1:1.0 (usb)
UDEV_LOG=3
ACTION=add
Sorry, that problem was with Gutsy. Other problems, similar to the ones
reported by hectorC started with Feisty for me, too.
--
UDEV problem with madfu-firmware for M-Audio Transit USB audio interface under
Feisty
https://bugs.launchpad.net/bugs/102631
You received this bug notification because
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
21 matches
Mail list logo
