USB 1.1 audio devices tend to stress the available bandwidth due to the way the isochronous mode is designed. It makes them 'special' in many ways, and this is one of the cases the Linux EHCI scheduler wasn't designed to handle at all, and has simply been hacked here and there to add support or 'improve' things without actually fixing the design problems. When I offered a fixed version, there was relatively little interest in accepting it (it needed a shakedown and debugging period; big change). The Linux USB stack design is highly unusual in several fundamental ways, and it complicates the problem (it would be a very elegant design for completely async/demand driven devices like mice, so on, it falls flat for fixed bandwidth devices). To be fair, the EHCI design is fraught with complexity and serious races, and even the good drivers like the one in MacOSX have special hacks for dealing with audio devices (this is assuming the MacOSX driver is the same as the one used in Darwin. It appears to be from protocol sniffing. The Darwin driver has several unique scheduling properties, like putting all the interrupt queue heads up front...). At this point, I despair Linux USB ever being reliably workable for USB1.1 audio devices. The kernel devs really do not believe there is any problem. Perhaps things will be a little better for the USB 2.0 audio class once it becomes more common, if it ever becomes common. Unfortunately, things seem to be repeating themselves-- isochronous devices do not work at all on the new 3.0 ports (XHCI). Monty _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
