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