Excerpts from Jeremy Jongepier's message of 2010-09-17 15:37:52 +0200: > On 09/15/2010 09:59 AM, Jeremy Jongepier wrote: > > On 09/14/2010 06:26 PM, Monty Montgomery wrote: > >> On Tue, Sep 14, 2010 at 8:29 AM, Jeremy Jongepier <jeremy@xxxxxxxxxxxxxx> wrote: > >>> On 09/14/2010 02:23 PM, Clemens Ladisch wrote: > >>>> Jeremy Jongepier wrote: > >>>>> cannot submit datapipe for urb 0, error -28: not enough bandwidth > >>>> > >>>> Is CONFIG_USB_EHCI_TT_NEWSCHED enabled in your kernel's configuration? > >>>> > >>>> Can you try with or without a hub? > >>>> > >>> > >>> I can't try with a hub, I don't have any. > >> > >> The bandwidth has been fragmented by other devices. USB-1 audio > >> devices require large _contiguous_ blocks of bandwidth schedule, and a > >> mouse or whatever that has carved its tiny little block out of the > >> middle of the bandwidth schedule makes all the bandwidth on either > >> side useless to an isochronous device. Simply unplugging it (or > >> whatever caused the scheduling problem) is not enough; the schedule > >> remains fragmented, as the linux EHCI driver does not know how to > >> reconsolidate fragmented bandwidth chunks. You have to rmmod EHCI or > >> reboot to get a fresh start. > >> > >> It's possible you're on a hub and don't know it. Most machines with > >> multiple USB ports are actually using a single controller and a built > >> in hub. Hubs make things *far* worse, as the hub is a dumb puppet > >> controlled entirely by the host controller, and Linux's hub scheduling > >> algorithm (even the 'new improved' one mentioned above) is rather > >> poor. I wrote a new one years ago that approached theoretical maximum > >> efficiency and could rebalance/reconsolidate the schedule, but I > >> couldn't keep up with repatching it during the complete free-for-all > >> that has been kernel 2.6 (I'd literally spent months of full-time work > >> *just* keeping up with the churn) and it was dropped from -mm. > >> > >> Monty > > > > Hello Monty, > > > > I've tried with all the ports on the machine but alas, forgot to run > > lsusb so I don't know how many USB buses there are available. I use a > > real-time kernel with rtirq though and will prioritize USB to see if > > that helps. > > > > Best, > > > > Jeremy > > I've checked with lsusb. Only two buses, and even if I try the least > crowded bus and use rtirq to prioritize that bus my UA-25 refuses to > work in duplex mode. So it might be that I'm behind a hub after all and > it's probably got nothing to do with a buggy USB chipset in my case. > But I already had a suspicion that USB soundcards wouldn't work on this > machine so I've equipped it with a decent FireWire PCIe card (the one on > the motherboard is crap also) and a FireWire soundcard. > > Best, > > Jeremy You're aware that duplex only works for 44k1 and 48k samplerates? My UA-25 works in duplex just fine with both 44k1 and 48k in advanced mode. -- Philipp -- "Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
