Comment 71 for bug 1136110

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
> >> regression.
> >>
> >> The bug is described in detail here:
> >>
> >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110?comments=all
> >>
> >> 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?
>
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110

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