Brendan Jones wrote: > 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@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
