linuxaudio.org

Brendan Jones wrote:

quoted text
> On 11/08/2011 10:55 PM, Clemens Ladisch wrote:

>> Jeremy Jongepier wrote:

>>> On 11/07/2011 10:53 PM, Pablo Fernández wrote:

>>>> I have not tried the patch yet but it seems to work if you read the

>>>> whole thread in alsa-users. Has someone else tried? Joan? Jeremy?

>>>

>>> Thanks for the links, unfortunately I have no access to a machine with

>>> such a chipset anymore (new job).

>>

>> This problem affects all full speed (i.e., most) audio devices connected

>> through a high-speed hub, so it could be reproduced on all machines, if

>> actually desired. :)  The problem with Intel's "rate matching" chipset

>> controller is that it has a built-in hub which cannot be disabled.

>

> So what your saying is there is no way way around it? Originally I

> thought is was limited to a particular chipset - is impossible to find

> the bandwidth on the bus?

There seems to be a miserunderstanding.
The Linux EHCI driver has (and has always had) a bug in the TT scheduler

that makes it unable to allocate enough bandwidth for more than one

stream for full-speed audio devices connected through a high-speed hub.
The mentioned patch fixes this bug (mostly).
As long as the patch didn't exist, a workaround was to connect the

device directly to the computer (so that not EHCI but another controller

would be used).  This workaround is not possible with recent Intel

chipsets because those have only EHCI controllers and handle high-speed

devices with a built-in hub.
All this is completely unrelated with a hardware bug in the first

revision of these Intel chipsets, which made USB audio just break.
Regards,

Clemens

_______________________________________________

Linux-audio-user mailing list

Linux-audio-user@lists.linuxaudio.org

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