[LAU] USB audio interface and a buggy USB controller

Jeremy Jongepier jeremy at autostatic.com
Sat Sep 18 11:31:43 UTC 2010


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 at autostatic.com>  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


More information about the Linux-audio-user mailing list