[alsa-devel] Asynchronous audio USB chips: choppy playback since 3.8-rc7
david.henningsson at canonical.com
Wed Apr 24 20:30:35 CEST 2013
On 04/19/2013 10:48 PM, Alan Stern wrote:
> On Fri, 19 Apr 2013, Daniel Mack wrote:
>> On 03.04.2013 12:25, Takashi Iwai wrote:
>>> At Wed, 03 Apr 2013 12:15:25 +0200,
>>> David Henningsson wrote:
>>>> Hi ALSA developers,
>>>> Just to get your attention here on what seems to be an USB audio
>>>> The bug is described in detail here:
>>>> Quoting the bug:
>>>> This bug seems to affect only a certain kind of hardware, which is
>>>> called "Asynchronous USB Digital Audio Codec (DAC)". It's said that such
>>>> a DAC hosts the clock itself (USB Device Host). An ordinary DAC, so
>>>> called "Synchronous USB DAC", uses the clock hosted by the mother board,
>>>> which is not affected by this bug.
>>>> When this bug affects an asynchronous USB DAC, the audio played by the
>>>> DAC is constantly interrupted. The playback itself does not stop, but
>>>> the output becomes discontinous, filling with constant crackling noises,
>>>> destroying everything the DAC plays.
>>>> According to the bug reporter, which seems to have done quite a bit of
>>>> research, this started between 3.8-rc6 and 3.8-rc7 as well as stable
>>>> kernels and the bug also lists a few commits which could be the cause,
>>>> none under sound/usb though.
>>> Yes, there is no commits regarding usb-audio itself between 3.8-rc6
>>> and rc7, so the likely culprit is in drivers/usb (usually either
>>> drivers/usb/host or drivers/usb/core). There are a bunch of changes
>>> there, so further bisection would be appreciated.
>> Ok, Joseph Salisbury has build some bisection kernels, and Tyson Tan
>> relentlessly tested all of them, and it turns out that
>> 3e619d0415 ("USB: EHCI: fix bug in scheduling periodic split transfers")
>> Is the first bad commit. Also, reverting this commit from the current
>> mainline head makes the problem disappear.
>> Alan, any idea?
> No ideas as to the cause.
> For debugging, it would help to see a usbmon trace from a kernel where
> the problem occurs, together with a trace from another kernel where the
> problem does not occur.
> Alan Stern
First, thanks for looking at this bug.
While a long-term solution is being discussed, this patch went to stable
too, where it is causing regressions. Would it be okay just to revert
this patch in the next stable series? (Even if this was a bug fix, few
people seem to have noticed?) Or do you envision something else
happening but the original -ENOSPC error showing up, due to other stuff
that went to stable at the same time?
David Henningsson, Canonical Ltd.
More information about the Alsa-devel