Sorry Gabriel, USB interface is any one of the M-Audio Line. FastTrack USB, FastTrack Pro, MobilePre USB... In other words multiple interfaces have been tested. This problem is specific to this machine... dmsg, lsusb, lsusb -t [ 46.458327] ALSA urb.c:480: frame 0 active: -75 [ 46.461327] ALSA urb.c:480: frame 0 active: -75 [ 46.463328] ALSA urb.c:480: frame 0 active: -75 [ 46.466328] ALSA urb.c:480: frame 0 active: -75 [ 46.468329] ALSA urb.c:480: frame 0 active: -75 [ 46.472326] ALSA urb.c:480: frame 0 active: -75 [ 46.475327] ALSA urb.c:480: frame 0 active: -75 [ 46.479328] ALSA urb.c:480: frame 0 active: -75 [ 46.482328] ALSA urb.c:480: frame 0 active: -75 [ 46.487329] ALSA urb.c:480: frame 0 active: -75 [ 46.489329] ALSA urb.c:480: frame 0 active: -75 [ 46.494290] ALSA urb.c:480: frame 0 active: -75 [ 46.498322] ALSA urb.c:480: frame 0 active: -75 [ 46.501287] ALSA urb.c:480: frame 0 active: -75 [ 46.508331] ALSA urb.c:480: frame 0 active: -75 [ 46.560332] ALSA urb.c:480: frame 0 active: -75 [ 98.971734] ALSA urb.c:146: timeout: still 7 active urbs.. [ 104.970917] ALSA urb.c:146: timeout: still 2 active urbs.. [ 121.260876] ALSA pcm.c:223: 4:2:1: usb_set_interface failed Bus 004 Device 002: ID 046d:c31c Logitech, Inc. Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 004: ID 0763:200f Midiman M-Audio MobilePre Bus 003 Device 003: ID 15ca:00c3 Textech International Ltd. Mini Optical Mouse Bus 003 Device 002: ID 0408:3001 Quanta Computer, Inc. Optical Touch Screen Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ohci_hcd/6p, 12M |__ Port 3: Dev 2, If 0, Class=HID, Driver=usbhid, 1.5M |__ Port 3: Dev 2, If 1, Class=HID, Driver=usbhid, 1.5M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ohci_hcd/6p, 12M |__ Port 3: Dev 3, If 0, Class=HID, Driver=usbhid, 1.5M |__ Port 4: Dev 4, If 0, Class=audio, Driver=snd-usb-audio, 12M |__ Port 4: Dev 4, If 1, Class=audio, Driver=snd-usb-audio, 12M |__ Port 4: Dev 4, If 2, Class=audio, Driver=snd-usb-audio, 12M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/6p, 480M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/6p, 480M ...Rods ;-) On Wed, Feb 2, 2011 at 09:58, Gabriel Beddingfield <gabrbedd(a)gmail.com>wrote;wrote:

Tried all the different ports I could. Seems I can't get it on the EHCI buses no matter which ports I use. Even replugged the front USB cable to the other ports but it always comes back on the two OHCI busses. Am thinking of buying a separate PCIE USB card as a temporary work around... I've had to cancel my studio sessions for the week on account of the systems being down. ARG! ...Rods ;-) On Wed, Feb 2, 2011 at 10:48, Gabriel Beddingfield <gabrbedd(a)gmail.com>wrote;wrote:

I already did that. Unplugged ALL the devices EXCEPT the Audio Interface. Even pulled my keyboard and mouse! This does not appear to be a USB sharing problem. ...Rods ;-) On Wed, Feb 2, 2011 at 11:07, Gabriel Beddingfield <gabrbedd(a)gmail.com>wrote;wrote:

Neither of those lines have anything that looks like it would trigger an error. There are no KERN_ERR calls remotely close. http://lxr.free-electrons.com/source/drivers/usb/core/urb.c ...Rods ;-) On Wed, Feb 2, 2011 at 11:20, Gabriel Beddingfield <gabrbedd(a)gmail.com>wrote;wrote:

I was looking at the wrong urb.c file. The correct one is linux-kernel/sound/usb/urb.c Actually the KERN_ERR is on 138 for my version triggers as line 146... On line 460 is the second KERN_ERR. This is all in a function called retire_capture_urb() It appears that there is a commented continue that would drastically change the for-loop this one is in. I wonder... Could this be the offending line? If I'm reading the code correctly it appears to be some sort of locking mechanism check while retiring the urb from use to make sure it is retired when it is no longer active. Without the continue the urb will still be retired. Perhaps this is causing something unstable? Clemens might know more about this. I'm not that familiar with kernel code. ...Rods ;-) On Wed, Feb 2, 2011 at 11:53, Gabriel Beddingfield <gabrbedd(a)gmail.com>wrote;wrote:

Ubuntu Linux 2.6.35-25-generic http://packages.ubuntu.com/maverick-updates/linux-image-2.6.35-25-generic I've tried various kernels from 2.6.32 to 2.6.35 various Ubuntu and Debian kernels. All experience the same. I have not yet compiled a kernel myself since it's a lot of work and the performance gains are negligible. Since the problem persists in all kernels I've tried it makes me suspect that the bug is in the master tree not something that was added on in a distro kernel. That sounds consistent with my reports. It's speculation, but at least we have that... I bought two PCI USB cards to test against. One is PCI Express USB 3.0 the other is PCI USB 2.0 - I'll report the results. Assuming that the on-board hardware is being unusually slow - this ought to fix it. If it's deeper in the core hardware I should probably scrap this board and get something that works properly. Either way I ought to know something soon. :-D I'll add the USB cards tonight. Stay tuned! :-D ...Rods ;-)

On 02/03/2011 12:40 AM, Rods Bobavich wrote: You don't have to test that one, it most probably won't work. Best, Jeremy

Rods Bobavich wrote: Thank you for not mentioning this message on alsa-devel. In the context of USB, the error code -75 means "babble", which is a technical term from the USB specification that means that the device sent some data at a time when it shouldn't (or at least the controller thinks so). As a result of that, the USB controller driver gets wedged. This looks like a hardware problem with your USB controller. Please try the latest kernel; there were added some workarounds recently. You might also try connecting the device through a hub (but there are some bugs in the EHCI driver which might make it think that it cannot schedule enough bandwidth for full duplex). No, this has nothing to do with USB. This message typically occurs on AMD system with C1E enabled, and is harmless. Regards, Clemens -- Don't anthropomorphize computers; they don't like it.