linuxaudio.org

On 09/18/2010 08:58 AM, Philipp Überbacher wrote:

quoted text
> 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  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@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-user