Re: USB audio interface and a buggy USB controller

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

 



On 09/18/2010 08:58 AM, Philipp Überbacher wrote:
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.

Hello Philipp,

Yes I know, I was testing with 48Khz samplerate in advanced mode.

Best,

Jeremy
_______________________________________________
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