Re: USB audio interface and a buggy USB controller

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Sound]     [ALSA Users]     [Pulse Audio]     [ALSA Devel]     [Sox Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux