USB Audio Codec choppy playback

[Tyson Tan]

1) The release of Ubuntu using
Ubuntu 12.10 AMD64.
Ubuntu 13.04 AMD64, daily build as new as 20130314.

2) The version of the package used
linux-image-3.5.0-26-generic
linux-image-3.5.7-03050706-generic_3.5.7-03050706.201302221435_amd64.deb
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.5.7.6-quantal/
linux-image-3.7.7-030707-generic_3.7.7-030707.201302111436_amd64.deb
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.7.7-raring/
linux-image-3.8.0-030800rc7-generic_3.8.0-030800rc7.201302081635_amd64.deb
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.8-rc7-raring/

This bug had been confirmed appearing after the following kernel upgrade step:
v3.5.0-25 > v3.5.0-26 ~ v3.5.0-27
v3.5.7.5 > v3.5.7.6 ~ v3.5.7.8
v3.7.6 > v3.7.7 ~ v3.7.10
v3.8.0-rc6 > v3.8.0-rc7 ~ v3.8.5
The v3.9 branch has been affected since its very first release.
v3.9-rc1, v3.9-rc2, v3.9-rc3 v3.9-rc4 are all affected.

3) What you expected to happen
When using a USB DAC to play audio, the audio should be played normally without any interruption.

4) What happened instead
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.

Using CLI command grep device.buffering to get the buffer from the devices, those affected kernels are reporting back a different number to the unaffected devices. The choppy noise is very similar to the situation when buffer size is not correctly set.

I have tested four USB DACs, two Asynchronous and two Synchronous. Only the Asynchronous ones are affected by this bug.

Affected Devices:
Arce MDAC5
Arce MDAC mini
Ayre Acoustics QB-9
Dragonfly USB DAC
Musical Fidelity v2 DAC

USB Audio Streaming Controller on affected devices:
Texas Instrument TAS1020
http://www.ti.com/product/tas1020

Audio DAC on affected devices:
Texas Instruments PCM1742
http://www.ti.com/product/pcm1742

This bug had been confirmed appearing after the following kernel upgrade step:
3.5.0-25 > 3.5.0-26
3.5.7.5 > 3.5.7.6 (and all 3.5.7.x above)
3.7.6 > 3.7.7 (and all 3.7.x above)
3.8.0-rc6 > 3.8.0-rc7 (and all 3.8.x above)
I used Kdiff to find the similar patches, and find the following patches suspicous:
USB: XHCI: fix memory leak of URB-private data
(appeared in 3.5.7.6/3.7.7/3.8.0-rc7)
USB: EHCI: fix for leaking isochronous data
(appeared in 3.7.7/3.8.0-rc7)
usb: Prevent dead ports when xhci is not enabled
(appeared in 3.5.7.6/3.7.7/3.8.0-rc7)
usb: Using correct way to clear usb3.0 device's remote wakeup feature
(appeared in 3.5.7.6/3.7.7/3.8.0-rc7)
USB: EHCI: remove ASS/PSS polling timeout
(appeared in 3.7.7/3.8.0-rc7)
USB: EHCI: unlink one async QH at a time
(appeared in 3.7.7/3.8.0-rc7)
USB: EHCI: fix timer bug affecting port resume
(appeared in 3.5.7.6/3.7.7/3.8.0-rc7)
USB: EHCI: fix bug in scheduling periodic split transfers
(appeared in 3.5.7.6/3.7.7/3.8.0-rc7)

Hope someone can look into this bug soon!

---
ApportVersion: 2.6.1-0ubuntu10
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: tysontan 2117 F.... pulseaudio
 /dev/snd/controlC1: tysontan 2117 F.... pulseaudio
 /dev/snd/pcmC1D0p: tysontan 2117 F...m pulseaudio
CRDA: Error: command ['iw', 'reg', 'get'] failed with exit code 1: nl80211 not found.
DistroRelease: Ubuntu 12.10
HibernationDevice: RESUME=UUID=8545c3e2-caba-4eaa-8fa4-2fbebcc2d9bb
InstallationDate: Installed on 2013-02-15 (14 days ago)
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release amd64 (20121017.5)
IwConfig:
 eth0 no wireless extensions.

 lo no wireless extensions.
MachineType: LENOVO 0053A11
MarkForUpload: True
Package: linux 3.5.0.26.32
PackageArchitecture: amd64
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.5.0-26-generic root=UUID=8c60a142-505f-4d74-afa0-37686558e86e ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 3.5.0-26.40-generic 3.5.7.6
RelatedPackageVersions:
 linux-restricted-modules-3.5.0-26-generic N/A
 linux-backports-modules-3.5.0-26-generic N/A
 linux-firmware 1.95
RfKill:

Tags: quantal package-from-proposed running-unity third-party-packages
Uname: Linux 3.5.0-26-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
dmi.bios.date: 10/11/2012
dmi.bios.vendor: LENOVO
dmi.bios.version: 6QET70WW (1.40 )
dmi.board.name: 0053A11
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr6QET70WW(1.40):bd10/11/2012:svnLENOVO:pn0053A11:pvrThinkPadX201Tablet:rvnLENOVO:rn0053A11:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 0053A11
dmi.product.version: ThinkPad X201 Tablet
dmi.sys.vendor: LENOVO

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1136110

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.8 kernel[0] (Not a kernel in the daily directory) and install both the linux-image and linux-image-extra .deb packages.

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.8-raring/

[Tyson Tan (tysontan)]

Hi, Joseph, thank you for the prompt reply.
I've tried the newset kernel 3.8.1, but unfortunately it had the same issue too.

The packages I installed were:
linux-headers-3.8.1-030801_3.8.1-030801.201302280935_all.deb
linux-headers-3.8.1-030801-generic_3.8.1-030801.201302280935_amd64.deb
linux-image-3.8.1-030801-generic_3.8.1-030801.201302280935_amd64.deb
linux-image-extra-3.8.1-030801-generic_3.8.1-030801.201302280935_amd64.deb

[Tyson Tan (tysontan)]

apport information

[Tyson Tan (tysontan)]

apport information

[Tyson Tan (tysontan)]

apport information

[Tyson Tan (tysontan)]

apport information

[Tyson Tan (tysontan)]

apport information

[Tyson Tan (tysontan)]

apport information

[Tyson Tan (tysontan)]

apport information

[Tyson Tan (tysontan)]

apport information

[Tyson Tan (tysontan)]

apport information

[Tyson Tan (tysontan)]

apport information

[Tyson Tan (tysontan)]

apport information

[Tyson Tan (tysontan)]

apport information

[Tyson Tan (tysontan)]

apport information

[Tyson Tan (tysontan)]

I've singled out one modification that might be responsible for this issue:

  * ALSA: usb-audio: fix invalid length check for RME and other UAC 2
    devices
    - LP: #1119885

[Tyson Tan (tysontan)]

I've finished the test on all available kernels. "kernel-bug-exists-upstream" has been added to the tags, the bug description has also been updated according to my test result. Good luck on fixing the bug!

[Tyson Tan (tysontan)]

Tested on linux kernel 3.8.3, still not working.
Tested on one more asynchronous USB DAC, and one other synchronous USB DAC, reproduced exactly the same issue in the description.

[Tyson Tan (tysontan)]

USB Audio Streaming Controller on affected devices:
Texas Instrument TAS1020
http://www.ti.com/product/tas1020

[Tyson Tan (tysontan)]

Audio DAC on affected devices:
Texas Instruments PCM1742
http://www.ti.com/product/pcm1742

[Tyson Tan (tysontan)]

Tested on linux kernel 3.9.0-rc3, still not fixed.

[Jan (ya-me)]

I have same problem with my Musical Fidelity v2 DAC (async). Why is this still not fixed? Any way to mokney patch this?

[Tyson Tan (tysontan)]

>Jan (ya-me)
If you are affected by this issue, please help by selecting "Yes, it affects me" by clicking the yellow pencil icon right side of the green text "This bug affects X people. Does this bug affect you?". It can be found somewhere below the title. This will increase the "heat" of the bug and hopefully more people can see it.

[Tyson Tan (tysontan)]

Added:
Using CLI command grep device.buffering to get the buffer from the devices, those affected kernels are reporting back a different number to the unaffected devices. The choppy noise is very similar to the situation when buffer size is not correctly set.

Added:
Affected Devices:
Arce MDAC5
Arce MDAC mini
Ayre Acoustics QB-9
Musical Fidelity v2 DAC

[Jan (ya-me)]

This is ridiculous, its been for a month and noone is bothering to fix. Is there any way to patch this locally?

[Jan (ya-me)]

Even Windows XP works with async DAC's, come on.

[Tyson Tan (tysontan)]

Tested on linux kernel 3.8.4, still not fixed.

>Jan (ya-me)
From the change log of the recent Linux Kernel releases, It seems that the developers are busy tinkering with the kernel to add new features to the USB related modules. When those new features are fully implemented, hopefully they will look into all the regressions made in the progress. It's also possible that this regression be fixed by some other commits, without being noticed by the developer at all. Let's give the developers some more time. Meanwhile, we can still use an older kernel as a temporary workaround.

[Joseph Salisbury (jsalisbury)]

Did this bug not happen with the 3.8.0-rc6 kernel? If that is the case, I can perform a bisect to identify the commit that introduced this regression.

Also, the v3.9-rc3 kernel is now available. Can you also test that kernel, to see if this is already fixed in mainline?
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.9-rc3-raring/

Thanks in advance!

[Jeffrey Ratcliffe (jeffreyratcliffe)]

On Mythbuntu 12.04, upgrading from linux-image-3.5.0-25-generic to linux-image-3.5.0-26-generic, caused the audio from my HDMI port to become choppy. Booting back into linux-image-3.5.0-25-generic fixes things.

$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: HDMI [HDA ATI HDMI], device 3: HDMI 0 [HDMI 0]

[Tyson Tan (tysontan)]

Joseph Salisbury>
I had tested v3.9-rc3 on 2013-03-21, it didn't fix the problem. (#22 comment)
v3.8.4, v 3.5.0.-27 did't fix the problem either.

The bug description have been constantly updated with new information I discovered, too. Please have a look.

[Tyson Tan (tysontan)]

Joseph Salisbury>
Yes, this bug didn't happen with v3.8.0-rc6 kernel, but it happened with every new kernel release after that version. So far the newest version is v3.9-rc3 and it is also affected.

[Tyson Tan (tysontan)]

Tested with Linux kernel v3.9-rc4, problem remains.

[Jan (ya-me)]

Has anyone commited a patch yet, and if so, was the merge proposed?

[Tim Richardson (tim-richardson)]

Probably not interesting, but my Dragonfly USB async DAC has this problem as well in 13.04 (I just upgraded today, from 12.10 which worked perfectly)

[Tim Richardson (tim-richardson)]

With a Dragonfly USB DAC on 13.04 development 3.8.0-15-generic (64 bit) I get this bug.

Plugging it into an arch machine with 3.8.4 32 bit, there is no problem with my DAC.
So if it's upstream, it was fixed between 3.8.0 and 3.8.4
The DAC was working well with 64 bit 12.10. I upgraded to 13.04 only today and immediately ran into this problem, so in my case I can't say if it worked for earlier 13.04 kernels.

[Tyson Tan (tysontan)]

>Tim Richardson
In my case I have tested the AMD64 builds only. On the v3.8.x branch this bug has appeared since v3.8.0-rc7, every AMD 64 kernel since that version is affected, including v3.8.4 .

[Tyson Tan (tysontan)]

Tested with Linux kernel v3.8.5, problem remains.
Added Dragonfly USB DAC into the affected device list.

[Joseph Salisbury (jsalisbury)]

I started a kernel bisect between v3.8-rc6 final and v3.8-rc7. The kernel bisect will require testing of about 7-10 test kernels.

I built the first test kernel, up to the following commit:
ff7c60c580d9722f820d85c9c58ca55ecc1ee7c4

The test kernel can be downloaded from:
http://people.canonical.com/~jsalisbury/lp1136110

Can you test that kernel and report back if it has the bug or not. I will build the next test kernel based on your test results.

One thing to note, you will need to install both the linux-image and linux-image-extra .deb packages.

Thanks in advance

[Jan (ya-me)]

I've downloaded and installed kernel from http://people.canonical.com/~jsalisbury/lp1136110

Unfortunately, it didn't fix the issue on my async usb dac - Musical Fidelity V-DAC 2.

[Tyson Tan (tysontan)]

>Joseph Salisbury
Thank you for building the test kernels! :)
On my setup, I can confirm the kernel of commit: ff7c60c580d9722f820d85c9c58ca55ecc1ee7c4
 is affected by the bug.

>Jan
I think Joseph is trying to narrow down which modification to the newer kernels that has actually caused the regression. I suppose these bisect builds are made by including suspected modifications one by one to the originally unaffected v3.8.0-rc6 kernel, so that way we can singled out which modification is the real cause. After that, we can probably fix it.

[Jan (ya-me)]

Yes, I know. I will install all branches that he releases until the issue is fixed. I just reported that the first commit didn't fix it.

[Jarkko Sakkinen (jarkko-sakkinen)]

For me audio is fine when I play music with Chrome either with HTML5 or Flash but when I play it with mplayer (with different -ao parameters) or dragonplayer, the sound is choppy.

[Jarkko Sakkinen (jarkko-sakkinen)]

Also, if I kill pulseaudio temporarily (I have autospawn disabled so I'm able to kill with pulseaudio --kill) and play with mplayer, sound is still crackling..

[David Henningsson (diwic)]

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.

--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

[Takashi Iwai (tiwai)]

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.

Takashi

[Clemens Ladisch (clemens-ladisch)]

> Using CLI command grep device.buffering to get the buffer from the devices,
> those affected kernels are reporting back a different number to the unaffected
> devices.

What grep command? And what are the different values?

[Tyson Tan (tysontan)]

##CLI COMMAND
grep device.buffering -B 10

##RETURNS
I: [pulseaudio] sink.c: device.bus_path = "pci-0000:00:1a.0-usb-0:1.5.4:1.0"
I: [pulseaudio] sink.c: sysfs.path = "/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.5/1-1.5.4/1-1.5.4:1.0/sound/card1"
I: [pulseaudio] sink.c: udev.id = "usb-Arce_MDAC_5.01-00-M501"
I: [pulseaudio] sink.c: device.bus = "usb"
I: [pulseaudio] sink.c: device.vendor.id = "0451"
I: [pulseaudio] sink.c: device.vendor.name = "Texas Instruments, Inc."
I: [pulseaudio] sink.c: device.product.id = "1020"
I: [pulseaudio] sink.c: device.product.name = "MDAC 5.01"
I: [pulseaudio] sink.c: device.serial = "Arce_MDAC_5.01"
I: [pulseaudio] sink.c: device.string = "front:1"
...(continue below)

##OLD KERNEL BUFFER SIZE
I: [pulseaudio] sink.c: device.buffering.buffer_size = "1048572"
I: [pulseaudio] sink.c: device.buffering.fragment_size = "524286"

##NEW KERNEL BUFFER SIZE
I: [pulseaudio] sink.c: device.buffering.buffer_size = "529200"
I: [pulseaudio] sink.c: device.buffering.fragment_size = "264600"

[zonque (g-canonical-zonque-org)]

Anyone who's affected and able to build own kernels, please try and revert these two patches that went in between 3.8-rc6 and 3.8-rc7:

 3e619d041 "USB: EHCI: fix bug in scheduling periodic split transfers"
 b09a61cc0 "USB: EHCI: fix for leaking isochronous data"

The commit IDs are from the mainline repository and are different for stable kernels, but that shouldn't matter.

[Michael Nazzareno Trimarchi (michael-t16qijz8x59bnuup5)]

Hi Daniel

On 03/04/13 12:23, Daniel Mack wrote:
> Hi David,
>
> On 03.04.2013 12:15, David Henningsson wrote:
>> 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.
>
> There were no relevant changes for snd-usb between the two versions
> mentioned. The only patches that come in mind in this time window are:
>
> 3e619d041 "USB: EHCI: fix bug in scheduling periodic split transfers"
> b09a61cc0 "USB: EHCI: fix for leaking isochronous data"

This last one, doesn't give me any problem, just a memory leak and not a choppy
playback (tested on 48Khz, 96Khz, 192Khz 32bit on OMAP3 device) and I don't
think that it can be the reason of the problem.

http://www.m2tech.biz/hiface_dac.html

Michael

>
> And they have both been back-ported to stable. Copied Alan for reference.
>
> Any chance some of the bug reporters could try and revert exactly those
> for testing?
>
>
> Thanks,
> Daniel
>
> _______________________________________________
> Alsa-devel mailing list
> <email address hidden>
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>

[Michael Nazzareno Trimarchi (michael-t16qijz8x59bnuup5)]

Hi Daniel

On 03/04/13 15:55, Michael Trimarchi wrote:
> Hi Daniel
>
> On 03/04/13 12:23, Daniel Mack wrote:
>> Hi David,
>>
>> On 03.04.2013 12:15, David Henningsson wrote:
>>> 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.
>>
>> There were no relevant changes for snd-usb between the two versions
>> mentioned. The only patches that come in mind in this time window are:
>>
>> 3e619d041 "USB: EHCI: fix bug in scheduling periodic split transfers"
>> b09a61cc0 "USB: EHCI: fix for leaking isochronous data"
>
> This last one, doesn't give me any problem, just a memory leak and not a choppy
> playback (tested on 48Khz, 96Khz, 192Khz 32bit on OMAP3 device) and I don't
> think that it can be the reason of the problem.

Sorry the comment was for a bug that is not included in this list and recently fixed.
USB: EHCI: fix bug in iTD/siTD DMA pool allocation

Michael

>
> http://www.m2tech.biz/hiface_dac.html
>
> Michael
>
>
>>
>> And they have both been back-ported to stable. Copied Alan for reference.
>>
>> Any chance some of the bug reporters could try and revert exactly those
>> for testing?
>>
>>
>> Thanks,
>> Daniel
>>
>> _______________________________________________
>> Alsa-devel mailing list
>> <email address hidden>
>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>>
>

[Michael Nazzareno Trimarchi (michael-t16qijz8x59bnuup5)]

Hi Daniel

On 03/04/13 17:00, Daniel Mack wrote:
> Hi Michael,
>
> On 03.04.2013 16:11, Michael Trimarchi wrote:
>> On 03/04/13 15:55, Michael Trimarchi wrote:
>>> On 03/04/13 12:23, Daniel Mack wrote:
>>>> Hi David,
>>>>
>>>> On 03.04.2013 12:15, David Henningsson wrote:
>>>>> 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.
>>>>
>>>> There were no relevant changes for snd-usb between the two versions
>>>> mentioned. The only patches that come in mind in this time window are:
>>>>
>>>> 3e619d041 "USB: EHCI: fix bug in scheduling periodic split transfers"
>>>> b09a61cc0 "USB: EHCI: fix for leaking isochronous data"
>>>
>>> This last one, doesn't give me any problem, just a memory leak and not a choppy
>>> playback (tested on 48Khz, 96Khz, 192Khz 32bit on OMAP3 device) and I don't
>>> think that it can be the reason of the problem.
>
> Is OMAP3 at all a platform that is affected by the bug? It seems the
> effect is only seen on some special host controller hardware anyway.
>

Yes, omap3 ehci and m2tech products is not affected and I'm testing a dac with internal clock.

>> Sorry the comment was for a bug that is not included in this list and recently fixed.
>> USB: EHCI: fix bug in iTD/siTD DMA pool allocation
>
> Sorry, you lost me. So what's the status of this issue now? Does "USB:
> EHCI: fix bug in iTD/siTD DMA pool allocation" fix it?

With or without it, I don't have any choppy audio and this is not a fix
of this bug.

>
> If not - and assuming you can reproduce the bug - which patches of the
> two I mentioned did you revert, and what was the effect of that? Did you
> try and remove both as well?

In my version I have the other two commits applied. I doubt that these two
commits are the reason of the choppy audio. What I can do, it test it on my
laptop tomorrow and send feedback result

Michael

>
>
> Thanks,
> Daniel
>

[Joseph Salisbury (jsalisbury)]

I built the next test kernel, up to the following commit:
3296944e29a048c06c5d724ef5c2c8c6e1297161

The test kernel can be downloaded from:
http://people.canonical.com/~jsalisbury/lp1136110

Can you test that kernel and report back if it has the bug or not. I will build the next test kernel based on your test results.

[Tyson Tan (tysontan)]

>Joseph Salisbury
I have just tested 3296944e29a048c06c5d724ef5c2c8c6e1297161,
This commit works normally without being affected by the bug.

[Joseph Salisbury (jsalisbury)]

I built the next test kernel, up to the following commit:
200e0d994d9d1919b28c87f1a5fb99a8e13b8a0f

The test kernel can be downloaded from:
http://people.canonical.com/~jsalisbury/lp1136110

Can you test that kernel and report back if it has the bug or not. I will build the next test kernel based on your test results.

[Tyson Tan (tysontan)]

I tested the following commit:
200e0d994d9d1919b28c87f1a5fb99a8e13b8a0f
filename: linux-image-3.8.0-030800rc5-generic_3.8.0-030800rc5.201304031425_amd64.deb

This commit is affected by the bug.

P.S. Please move each of those packages into their own directory. As the number of files increased, I begin to have difficulty finding the right one to download...^^b

[Joseph Salisbury (jsalisbury)]

I built the next test kernel, up to the following commit:
f292e7f9fb0e4bec68bbd83443407d6bb7922d36

The test kernel can be downloaded from:
http://people.canonical.com/~jsalisbury/lp1136110

Can you test that kernel and report back if it has the bug or not. I will build the next test kernel based on your test results.

[Tyson Tan (tysontan)]

I've tested the following commit:
f292e7f9fb0e4bec68bbd83443407d6bb7922d36
filename: linux-image-3.8.0-030800rc5-generic_3.8.0-030800rc5.201304041308_amd64.deb

This commit works normally. Not affected by the bug.

[Joseph Salisbury (jsalisbury)]

I built the next test kernel, up to the following commit:
3e619d04159be54b3daa0b7036b0ce9e067f4b5d

The test kernel can be downloaded from:
http://people.canonical.com/~jsalisbury/lp1136110

Can you test that kernel and report back if it has the bug or not. I will build the next test kernel based on your test results.

[Tyson Tan (tysontan)]

I tested the following commit:
3e619d04159be54b3daa0b7036b0ce9e067f4b5d
filename: linux-image-3.8.0-030800rc5-generic_3.8.0-030800rc5.201304051428_amd64.deb

This commit is affected by the bug.

[Jan (ya-me)]

jan@janpc:~$ uname -a
Linux janpc 3.8.0-030800rc5-generic #201304041308 SMP Thu Apr 4 17:09:42 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
jan@janpc:~$

Commit: f292e7f9fb0e4bec68bbd83443407d6bb7922d36

This kernel is not bugged. Tested with Musical Fidelity vdac2 async usb dac.
The other two kernels are bugged.

[Joseph Salisbury (jsalisbury)]

I built the next test kernel, up to the following commit:
78796ae17eacedcdcaaeb03ba73d2e532a4c8f83

The test kernel can be downloaded from:
http://people.canonical.com/~jsalisbury/lp1136110

Can you test that kernel and report back if it has the bug or not. I will build the next test kernel based on your test results.

[Tyson Tan (tysontan)]

I have tested the following commit:
 78796ae17eacedcdcaaeb03ba73d2e532a4c8f83
filename: linux-image-3.8.0-030800rc5-generic_3.8.0-030800rc5.201304101508_amd64.deb

This kernel is not affected by the bug.

[Joseph Salisbury (jsalisbury)]

I built the next test kernel, up to the following commit:
b09a61cc0bc2a7151f4ab652489e85253d5d0175

The test kernel can be downloaded from:
http://people.canonical.com/~jsalisbury/lp1136110

Can you test that kernel and report back if it has the bug or not. I will build the next test kernel based on your test results.

[Tyson Tan (tysontan)]

I have tested the following commit:
b09a61cc0bc2a7151f4ab652489e85253d5d0175

This kernel is not affected by the bug.

[Jan (ya-me)]

Hello,

I have noticed a problem with f292e7f9fb0e4bec68bbd83443407d6bb7922d36.
I've been running it on production machine for a while, and I've noticed that DAC stops working from time to time. Eg. it works fine for 8 hours and than all of the sudden sound dies. I have to plug out USB and plug it back in to fix the problem.

[Joseph Salisbury (jsalisbury)]

The bisect reports the following as the first bad commit:

3e619d04159be54b3daa0b7036b0ce9e067f4b5d is the first bad commit
commit 3e619d04159be54b3daa0b7036b0ce9e067f4b5d
Author: Alan Stern <email address hidden>
Date: Wed Jan 30 16:36:40 2013 -0500

    USB: EHCI: fix bug in scheduling periodic split transfers

I'll build a test kernel with that commit reverted and post a link to it.

[Tyson Tan (tysontan)]

>Joseph Salisbury
OK, thanks for helping us to build all those bisect kernels!
:)

[Joseph Salisbury (jsalisbury)]

I built a test kernel with commit 3e619d04159be54b3daa0b7036b0ce9e067f4b5d reverted.

The test kernel can be downloaded from:
http://people.canonical.com/~jsalisbury/lp1136110

Can you test that kernel and report back if it has the bug or not.

Thanks in advance!

[Tyson Tan (tysontan)]

I have tested the following packages:
linux-headers-3.8.0-19-generic_3.8.0-19.29~lp1136110v1_amd64.deb
linux-headers-3.8.0-19_3.8.0-19.29~lp1136110v1_all.deb
linux-image-3.8.0-19-generic_3.8.0-19.29~lp1136110v1_amd64.deb
linux-image-extra-3.8.0-19-generic_3.8.0-19.29~lp1136110v1_amd64.deb

They are not affected by the bug.
Thank you for building the test kernels!

[Alan Stern (stern)]

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

[Tyson Tan (tysontan)]

>Alan Stern
I have done an usbmon trace using the following kernel

$uname -a
Linux tysontan-ThinkPad-X201-Tablet 3.5.0-28-generic #47-Ubuntu SMP Tue Apr 9 19:03:54 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Using the mehtod described in the following URL:
https://www.kernel.org/doc/Documentation/usb/usbmon.txt

The raw file is attached in this comment.

[Tyson Tan (tysontan)]

I have also captured the USB device information of my test environment, just in case it's going to be needed, using CLI command sudo lsusb -v . Those information is saved as a text file and uploaded as the attachment of this comment.

Hope the information I had collected can be useful. Thanks in advace!

[Tyson Tan (tysontan)]

Sorry for overlooking part of the request in comment #71.
I have done an extra usbmon trace using the following kernel, which is not affected by this bug:

$ uname -a
Linux tysontan-ThinkPad-X201-Tablet 3.5.0-25-generic #39-Ubuntu SMP Mon Feb 25 18:26:58 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Using the mehtod described in the following URL:
https://www.kernel.org/doc/Documentation/usb/usbmon.txt

The raw file is attached in this comment.

[Tyson Tan (tysontan)]

Here is how I tested with usbmon trace:

1. Start PC with USB DAC is on.
2. Start 'cat' to trace USB.
3. Start Jack Audio Connection Kit Service (which ensures the audio stream is bit exact, sample rate exact).
4. Start Clementine.
5. Play a song for a few second, stop.
6. Play another song for a few second, stop.
7. Stop Jack Audio Connection Kit service.
8. Ctrl-C to stop 'cat' tracing USB.
9. Retrive the newly created raw file.

Additional information:

With unaffected kernels, when I start to play a song or double click to switch between songs during a current playback, an asynchronous USB DAC would produce one-second crack noise at the beginning of a song, while the main session of the playback is normal. Using Jack Audio Connection Kit as the audio service eliminates this one-second noise. A synchronous USB DAC does not produce such a noise, regardless of audio service I used.

With affected kernels, there is a very tiny chance that the bug does not occur when I start to play a song. When that happens, double click to switch between songs does not cause that one-second noise at the beginning of a song. However, if I stop the playback completely, the next playback would very likely be affect by the reported bug again.

[David Henningsson (diwic)]

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
>>>> 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

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.
https://launchpad.net/~diwic

[Alan Stern (stern)]

On Wed, 24 Apr 2013, David Henningsson wrote:

> >> 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
>
> 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?

I think reverting it from stable won't cause any new problems to show
up (although the original problem will return, obviously). Go ahead.

At the same time, it would be nice to know that some people are really
carrying out tests to find the reason for the new problem. Otherwise
we end up with this commit reverted and nobody trying to figure out how
to fix the original bug correctly.

Alan Stern

[Tyson Tan (tysontan)]

I took a look in the information of the commit that caused the regression:
https://patchwork.kernel.org/patch/2164101/
And I think there are some details to report:

1) So far as I know, the affected Asynchronous DACs are all USB 1.1 devices, and therefore low-speed (despite being labled as full speed).

2) A Synchronous USB connection uses a one way digital connection for music playback, while Asynchronous mode has a feedback loop so that the amount of data in the frame can be controlled (because an Asynchronous DAC has its own clock which is not synchronized with the host clock). Since there is extra bandwidth needed by the control here, I wonder if the two modes have different true bandwidth for payload data.

3) The crack noise sounds very similar to what caused by a wrong buffer-size setting. I can make the same noise with an unaffected kernel if the ALSA/PulseAudio buffer setting is too small.

Combining 2) and 3) and the patch description, is it possible that the choppy playback is caused by data overflow or partially dropping package content because Asynchronous mode provides less bandwidth than a normal (synchronous) connection?

I'm not a hardware professional, so I can only make some guesses here.

[Jan (ya-me)]

Would it be possible to fix affected kernels just by changing some setting?

[Alan Stern (stern)]

I didn't see the last few comments until today, because I wasn't subscribed to this bug report. Now I am.

The two usbmon traces don't seem to have any significant differences. The problem must lie at a lower level, probably something in the hardware. Is there any way you can try testing the device with a different type of computer?

In answer to the questions above:

1) USB 1.1 devices can be either full speed or low speed. This device is full speed. (Low-speed USB does not have enough bandwidth for high-quality audio and does not support isochronous transfers.)

2) The two modes do have different bandwidth requirements; both are well below the limits of full-speed USB. For example, the usbmon traces showed that the device was using no more than 273 bytes of data every millisecond, whereas full-speed USB can transfer over 1000 bytes of isochronous data per millisecond.

3) The buffer size is the same in the working and non-working cases, as far as I can tell.

The easiest way for me to work on this may be to buy one of these devices for testing here. Do you know if any of them are available from Amazon?

[Tim Richardson (tim-richardson)]

I'm not sure about the point of testing on different hardware ... We have
devices that used to work and now don't. Dragonfly USB DAC is cheap and
easily available.
On Apr 26, 2013 6:35 AM, "Alan Stern" <email address hidden> wrote:

> I didn't see the last few comments until today, because I wasn't
> subscribed to this bug report. Now I am.
>
> The two usbmon traces don't seem to have any significant differences.
> The problem must lie at a lower level, probably something in the
> hardware. Is there any way you can try testing the device with a
> different type of computer?
>
> In answer to the questions above:
>
> 1) USB 1.1 devices can be either full speed or low speed. This device
> is full speed. (Low-speed USB does not have enough bandwidth for high-
> quality audio and does not support isochronous transfers.)
>
> 2) The two modes do have different bandwidth requirements; both are well
> below the limits of full-speed USB. For example, the usbmon traces
> showed that the device was using no more than 273 bytes of data every
> millisecond, whereas full-speed USB can transfer over 1000 bytes of
> isochronous data per millisecond.
>
> 3) The buffer size is the same in the working and non-working cases, as
> far as I can tell.
>
> The easiest way for me to work on this may be to buy one of these
> devices for testing here. Do you know if any of them are available from
> Amazon?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1136110
>
> Title:
> USB Audio Codec choppy playback
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110/+subscriptions
>

[Alan Stern (stern)]

The point of testing on a different computer is to try and narrow down the location of the problem. If the problem persists then it's likely to be in the USB device. Otherwise it's likely to be in the computer's hardware or software.

I just realized that my own USB audio device uses asynchronous mode. (The lsusb output is attached so you can see for yourselves.) Unlike Tyson's device it supports only 16-bit audio, not 24-bit, but like his, it runs at full speed. And the usbmon output I get from it looks quite similar to the posted traces. However my device works just fine, no crackling noises or anything when running at 44100 samples/second.

So more testing is needed. Here's the next thing to try. This will require a kernel that was built with CONFIG_USB_DEBUG enabled. Go to the appropriate subdirectory of /sys/kernel/debug/usb/ehci/. On Tyson's system that would be the 0000:00:1a.0 directory (because the EHCI controller for bus 1 is named 0000:00:1a.0). While the crackly audio is playing make a copy of the "periodic" file, and then attach the copy to this bug report.

It would be great also to see the same thing for a kernel that doesn't have the troublesome commit.

[Tyson Tan (tysontan)]

It seems that Alan's asynchronous DAC is not the only one that worked fine. My friend has an Arce MDAC2 which however is labeled "asynchronous", not affected by this bug. That DAC supports only two sample rates: 44100Hz and 48000Hz at 16bit. I happen to know it use a BB PCM1792 as its DAC chip, but not sure about the USB controller chip. It might be BB PCM2707. Arce MDAC2 has a BB SRC4392 that asynchronously upsamples input audio to 192Khz to reduce jitter, which is the reason it's labeled "asynchronous".

I searched google and find this article: http://www.pstracks.com/pauls-posts/myth-asynchronous-dac/6291/
"Now, many DACS have asynchronous USB inputs, but that doesn’t mean they are an asynchronous DAC. To qualify as an asynchronous DAC, every input of the DAC (not just the USB) would be asynchronous – where the designer would throw away the source clock and rely only on the DAC’S internal clock. There are scarce few of these around."

According to this article, since Arce MDAC2 is still using the source clock, it can not qualify as a "real" asynchronous DAC.

As for the CONFIG_USB_DEBUG enabled kernel, I haven't built a linux kernel before, but I'll try to figure it out later.

[Tim Richardson (tim-richardson)]

This is my DAC. It is a genuine async DAC.

http://www.audioquest.com/usb_digital_analog_converter/dragonfly-dac

available on amazon
http://www.amazon.com/AudioQuest-DragonFly-Asynchronous-Digital-Audio-Converter/dp/B00882U782

[Tim Richardson (tim-richardson)]

I tried mainline 3.8.8 i386 from the kubuntu kernel ppa. The dac is still unusable.
However on a different machine with arch i686 and 3.8.8 it works.
I will see if I can provide the debug for this.

[Jan (ya-me)]

I have tested:
linux-headers-3.8.0-19-generic_3.8.0-19.29~lp1136110v1_amd64.deb
linux-headers-3.8.0-19_3.8.0-19.29~lp1136110v1_all.deb
linux-image-3.8.0-19-generic_3.8.0-19.29~lp1136110v1_amd64.deb
linux-image-extra-3.8.0-19-generic_3.8.0-19.29~lp1136110v1_amd64.deb

On Ubuntu 13.04.

With Musical Fidelity V-DAC2 Async USB DAC. It works.

[Tim Richardson (tim-richardson)]

I made a 13.04 live USB, updated it which means in my case 32 bit 3.0.19.
Booted from this, the Dragonfly worked fine. However, the installed Ubuntu currently uses the mainline kernel 3.8.8 and the dragonfly doesn't work as described here.

3.0.19 isn't an option on this machine since it is a media PC, and 3.0.19 has a bug which means no HDMI audio, so I personally need to wait until the HDMI bug is fixed before I go back to Ubuntu kernels.

Possibly I have a configuration problem, and the issue is not kernel related. In which case, I will reinstall.

[Tim Richardson (tim-richardson)]

Tim Richardson wrote:
> I made a13.04 live USB, updated it which means in my case 32 bit3.0.19.
Correct is: 3.8.0-19

[alex brusenschii (z-baralgin)]

just for information.
My hardware is: laptop Dell 5420 and USB DAC "HiFiMeDIY Sabre USB DAC" with Tenor TE-7022L usb chip.
I noticed that I get crappy sound as soon as I connect bluetooth mouse. The laptop uses bluetooth module connected to USB internally (Dell Wireless 375 bluetooth module).
I experienced the problem sound on ubuntu kernel 3.2.x and on the latest one from 13.04 distro (both x64).

I home the information will help to fix the bug.

[Alan Stern (stern)]

Kernel version numbers, especially those used by Canonical, don't mean much to me. What matters is whether or not the kernel includes the troublesome commit identified in comment #67.

Joseph, can you build a pair of test kernels, one with the bad commit and one without, but both with CONFIG_USB_DEBUG enabled? Then maybe people could try them out and report back the debugging information I asked for in comment #82.

Tim, I'm afraid $248 is somewhat more than I want to spend merely for testing purposes. Especially given that there's no guarantee the device would fail in the same way on my computer (it probably is similar to your arch i686 machine).

[Joseph Salisbury (jsalisbury)]

Yes, Alan. I'll build those two kernels.

[Joseph Salisbury (jsalisbury)]

I built two test kernels. One with commit 3e619d04159be54b3daa0b7036b0ce9e067f4b5d reverted and one without that commit reverted. Both kernels have CONFIG_USB_DEBUG enabled. The kernels can be downloaded from:

http://kernel.ubuntu.com/~jsalisbury/lp1136110/commit-reverted/
http://kernel.ubuntu.com/~jsalisbury/lp1136110/commit-not-reverted/

Thanks again for all the assistance, Alan!

[Tyson Tan (tysontan)]

Hello Joseph,
The not-reverted debug kernel that you had just built fails to boot on my system.
http://kernel.ubuntu.com/~jsalisbury/lp1136110/commit-not-reverted/

I don't know much about this, but the file size for the images are very different to the reverted ones.
(reverted: 13M/30M) > (not-reverted 7M/64M)

[Wilbert van Bakel (wilbert-vanbakel)]

To me this seems a kernel scheduling problem and I experimented with the a few well know RT hacks.

Create the file /etc/security/limits.d/audio-limits.conf with the following content:

# /etc/security/limits.d/audio-limits.conf
@audio - rtprio 99
@audio - memlock 512000
@audio - nice -19

Reboot and then apply the following command:
for i in $(pgrep softirq); do chrt -f -p 99 $i; done

And check if you notice a difference, please?

[Alan Stern (stern)]

On Fri, 3 May 2013, Wilbert van Bakel wrote:

> To me this seems a kernel scheduling problem and I experimented with the
> a few well know RT hacks.

This cannot possibly be a scheduling problem. If it were, reverting
commit 3e619d04159be would not make any difference.

Alan Stern

[Tim Richardson (tim-richardson)]

I recently tried booting my media centre Ubuntu PC with a live 13.04 disk (updated to release .19 of the Ubuntu 13.04 kernel). My DAC worked flawlessly. Yet the installed version doesn't work.
What debugging steps can I do that may help work out why this is?
(yesterday I moved to the .20 kernel in raring-proposed which finally fixes the bug stopping HDMI audio from working, but the DAC is still unusable).

[Alan Stern (stern)]

The next debugging steps are described in comment #82. Nobody has done them yet.

[Jan (ya-me)]

For me neither live or installed version works.

[Tim Richardson (tim-richardson)]

Hi Alan, can you make a kernel with USB_DEBUG enabled based on the latest 8...20 kernel (may still be in raring-proposed).
This kernel fixes an HDMI audio bug so I need to use it on my media PC
I will do the comment #82 steps (assuming that I see the same thing: a working live-USB boot to contrast with the failing installed version). Thanks.

[Alan Stern (stern)]

I can't make any Canonical-type kernels (and I don't know what "8...20" means). But maybe Joseph can help you.

[Tim Richardson (tim-richardson)]

I'm compiling a kernel now, I hope with USB debug support added correctly.

[Tim Richardson (tim-richardson)]

Tim Richardson wrote:
> I'm compiling a kernel now, I hope with USB debug support added
> correctly.
>
This was a bit harder than I thought, because I don't know how to make
the live usb use a custom kernel. It doesn't boot with grub and my naive
attempts at tricking it to use my compiled kernel didn't work.

So I will find an older version of the kernel that I can use on the
problem box, and turn on USB debugging.
Exactly where in kernel config to I enable the necessary debugging options?

[Alan Stern (stern)]

The two symbols you need to enable are CONFIG_DEBUG_FS (which probably is enabled already) and CONFIG_USB_DEBUG.

[Joseph Salisbury (jsalisbury)]

@Tyson Tan,

Re: Comment #93. Is there an error message that you see when that kernel doesn't boot? I'm not sure why there is such a size difference, but I'll rebuild both kernels and post a link.

[Joseph Salisbury (jsalisbury)]

@Tyson Tan,

I re-built the two test kernels. One with commit 3e619d04159be54b3daa0b7036b0ce9e067f4b5d reverted and one without that commit reverted. Both kernels have CONFIG_USB_DEBUG enabled. The kernels can be downloaded from:

http://kernel.ubuntu.com/~jsalisbury/lp1136110/commit-reverted/
http://kernel.ubuntu.com/~jsalisbury/lp1136110/commit-not-reverted/

@Tim Richardson, you should be able to use these kernels for testing as well, assuming you use the 64 bit kernel. I can also build a 32 bit kernel if needed.

[Tim Richardson (tim-richardson)]

Joseph Salisbury wrote:
>
> @Tim Richardson, you should be able to use these kernels for testing as
> well, assuming you use the 64 bit kernel. I can also build a 32 bit
> kernel if needed.
32 bit would be great. Thanks.

[Tim Richardson (tim-richardson)]

Alan,
I've tried to build a kernel with CONFIG_USB_DEBUG.
In the config editor I searched for the symbol CONFIG_USB_DEBUG and only one match was found.
I set it, compiled and installed the kernel.
This kernel is:

root@whitlam:/boot# uname -r
3.7.0-7-generic

and from /boot/config-3.7.0-7-generic
there is only one reference to that symbol, but it is in the HID section which seems odd.

# USB HID Boot Protocol drivers
#
CONFIG_USB_KBD=m
CONFIG_USB_MOUSE=m
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB_ARCH_HAS_XHCI=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_COMMON=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB=y
CONFIG_USB_DEBUG=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y

The periodic file (comment #86) has data in it for one of the two devices, I assume that's the DAC whic is playing right now.

Q1. For this to help, do you need see exactly the same sound being played back (I don't know how to do this, but it must be easy to find a tone generator online)?

Q2. How much data do you need?

Here is some data I see. This is from the kernel above, which has no crackling. I'm hoping that you can confirm this is what you need.

0: qh2-0e01/efda8640 (f5 ep3in [1/3] q1 p32)
   1: qh256-0001/f6f98dc0 (h2 ep1in [1/0] q1 p2)
   2: qh2-0e01/efda8640
   4: qh2-0e01/efda8640
   6: qh2-0e01/efda8640
   8: qh2-0e01/efda8640
  10: qh2-0e01/efda8640
  12: qh2-0e01/efda8640
  14: qh2-0e01/efda8640
  16: qh2-0e01/efda8640
  18: qh2-0e01/efda8640
  20: qh2-0e01/efda8640
  22: qh2-0e01/efda8640
  24: qh2-0e01/efda8640
  26: qh2-0e01/efda8640
  28: qh2-0e01/efda8640
  30: qh2-0e01/efda8640
  32: qh2-0e01/efda8640
  34: qh2-0e01/efda8640
  36: qh2-0e01/efda8640
  38: qh2-0e01/efda8640
  40: qh2-0e01/efda8640
  42: qh2-0e01/efda8640

[Tim Richardson (tim-richardson)]

this is what I get from a buggy kernel
[ actually playing the same song from what it's worth :) ]

uname -r
3.8.0-20-generic

(but compiled with CONFIG_USB_DEBUG)

/sys/kernel/debug/usb/ehci/0000:00:1d.0/periodic

size = 1024
   0: qh2-0e01/f6bb3a80 (f5 ep3in [1/3] q1 p32)
   1: qh256-0001/f6aa4580 (h2 ep1in [1/0] q1 p2)
   2: qh2-0e01/f6bb3a80
   4: qh2-0e01/f6bb3a80
   6: qh2-0e01/f6bb3a80
   8: qh2-0e01/f6bb3a80
  10: qh2-0e01/f6bb3a80
  12: qh2-0e01/f6bb3a80
  14: qh2-0e01/f6bb3a80
  16: qh2-0e01/f6bb3a80
  18: qh2-0e01/f6bb3a80
  20: qh2-0e01/f6bb3a80
  22: qh2-0e01/f6bb3a80
  24: qh2-0e01/f6bb3a80
  26: qh2-0e01/f6bb3a80
  28: qh2-0e01/f6bb3a80
  30: qh2-0e01/f6bb3a80
  32: qh2-0e01/f6bb3a80
  34: qh2-0e01/f6bb3a80
  36: qh2-0e01/f6bb3a80
  38: qh2-0e01/f6bb3a80
  40: qh2-0e01/f6bb3a80
  42: qh2-0e01/f6bb3a80

[Alan Stern (stern)]

You did set CONFIG_USB_DEBUG correctly, as witnessed by the fact that the debugging directories and files now exist on your system. (Actually the HID section in your .config file is only two lines long; it ends after the "CONFIG_USB_MOUSE=m" line, but the end isn't marked in any way.)

The sound being played doesn't matter, so long as the sampling rate is the same on both the buggy and working kernels.

You can attach the entire file; it isn't tremendously big. What I really need to see are the lines marked with "sitd", plus at least one representative of the various "qh" lines.

[Toby Corkindale (tjc-wintrmute)]

This bug has been affecting me since upgrade to 13.04; 12.10 and 12.04 were fine.
This is on a FiiO E10 USB DAC.

It's not just slightly crackling -- it's completely mangled audio! Slowed down about 30% and full of extra noise.

I'm trying to work out if it's synchronous or not according to the lsusb output..
In there it says "Transfer type: Isochronous" and "Sync type: Adaptive" often.

[Tim Richardson (tim-richardson)]

This is the periodic file in the case of the working kernel
root@whitlam:/boot# uname -r
3.7.0-7-generic
32 bit

[Tim Richardson (tim-richardson)]

And this attachment is a bad kernel, an ubuntu 3.8 series (I get the same terrible sound on any current mainline kernel)

See attachment.

I really hope this helps.

[Alan Stern (stern)]

Okay, good, this does help. The difference between the two kernels shows up when you compare the lines that say "sitd1" -- the working kernel has "sitd1-003c" and the non-working kernel has "sitd1-0078".

While this difference is caused by the commit in question, it's more or less a coincidence that one value works and the other doesn't. The commit doesn't really make things worse than they already are; it's just that this part of the driver is in bad shape generally.

Before I try to do a poper fix, it would help to see the contents of /sys/kernel/debug/usb/devices while the audio is playing (on either kernel, it doesn't matter which).

[Tim Richardson (tim-richardson)]

Attached is devices, renames as devices.txt
Audio was playing. This was the "good" kernel.

[Alan Stern (stern)]

Just out of curiosity, does it make any difference if you remove the Logitech receiver?

(Not that I think this would be any sort of fix. A real code update is needed. I just wondered if it would change anything.)

[Alan Stern (stern)]

I'm not sure if this is worth it... Reverting that commit would be a lot more straightforward, and that's probably what I'll end up doing. However, this patch makes the driver "more correct" -- although it's still a long way from being right. But the only way to fix this properly is to rewrite a large chunk of the code, and that's just not feasible for a simple regression fix.

In the meantime, I'd like to know what happens when you apply this patch to the non-working kernel. Does the sound come out right? And either way, what does the "periodic" file say?

[Tim Richardson (tim-richardson)]

Ok, that patch fixes the problem. I changed nothing else (so Logitech USB keyboard still attached).

attached: periodic.txt

[Tim Richardson (tim-richardson)]

and now attached devices (as devices.txt) in case it helps.

[Alan Stern (stern)]

Thanks for testing. It's good to know that the patch works as intended and that it fixes the problem. It indicates that my understanding of what's going on with the hardware is basically right.

Nevertheless, I think the safest course will be to revert the commit. This part of the driver is in such bad shape that fixing one bug is likely to cause another one to surface (which in fact is exactly what happened to cause your problem in the first place).

Unless there are any objections, I'll submit the reversion next week.

[Andrejs Hanins (ahanins)]

Hi, just FYI, I faced the same bug on Ubuntu AMD64 13.04 and async USB Arcam rDAC. I tried the attached patch on top of vanilla 3.9.4 Kernel (last stable as for today) and it definitely did help also for me. No more choppiness whatsoever. Before the patch, choppiness happened in every 2-nd or so attempt to play through ALSA directly (pulse-audio is definitely unrelated).

[Jan (ya-me)]

Any ETA's on when the mainline Ubuntu 3.8 kernel will be patched/commit reverted?

[mp (m-p)]

Alan Stern (stern) wrote on 2013-05-24:

"Unless there are any objections, I'll submit the reversion next week."

Any update/news?

[mp (m-p)]

@ Joseph Salisbury

with this kernel, the problem still exists for me:

http://kernel.ubuntu.com/~jsalisbury/lp1136110/commit-reverted/

[Andrejs Hanins (ahanins)]

At least, I've been using the patch (i.e. listening USB audio) on top of 3.9.4 Kernel daily with my Arcam r-DAC on almost 2 weeks and seen no more choppiness or any new problems.

[mp (m-p)]

@ Andrejs Hanins:

Could you please specify *which* patch that is (incl. further instructions)?

thanks!

[Andrejs Hanins (ahanins)]

@ mp
The patch attached to this bug report named "fix some mistakes in ehci-hcd's split transaction scheduler". I just took vanilla (www.kernel.org) 3.9.4 Kernel, applied patch and compiled it for Ubuntu 13.04.

[mp (m-p)]

@ Andrejs Hanins:

Thanks for that clarification. For others looking for the same information, this is the patch:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110/+attachment/3685174/+files/ehci-split-bugs

Relatedly: Any with-patch-compiled kernels available for download anywhere, by any chance?

[Alan Stern (stern)]

I have submitted a reversion for commit 3e619d04159be54b3daa0b7036b0ce9e067f4b5d. It will appear probably in the 3.10-rc6 kernel and then in the next 3.9.stable kernel released after that.

[Joseph Salisbury (jsalisbury)]

Alan, thanks for all the help with this issue!

[Alan Stern (stern)]

Thanks to Tyson and Tim for all their testing.

[Tyson Tan (tysontan)]

Thank you for looking into this bug, Alan!
Thank you for building those kernels for us to test, Joseph!
And thank you Tim for testing the debug kernel because I couldn't risk breaking my working machine at the moment.
:)

[mp (m-p)]

Thank you all - looking forward to playing music again with the new kernel.

If anyone could specify how to use (apply) the patch:

"fix some mistakes in ehci-hcd's split transaction scheduler": https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110/+attachment/3685174/+files/ehci-split-bugs

... before compiling, then that would be really cool, as I have not been successful in doing so.

[Tyson Tan (tysontan)]

Today the revert landed on kernel v3.10-rc5.
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.10-rc5-saucy/
I've tested it and it worked. Finally I can use my DAC again. It had been half an year since.
Thank you all guys! :)

[Jan (ya-me)]

Will it ever get into mainline ubuntu 3.8?

[jazztickets (jazztickets)]

I have the Audioengine D1 and the only thing that fixes it is plugging it into this

http://www.amazon.com/AmazonBasics-USB-4-Port-Ultra-Mini/dp/B003M0NURK/ref=sr_1_1?ie=UTF8&qid=1371414908&sr=8-1&keywords=amazon+usb+hub

Which forces the D1 to use ehci instead of uhci.

[Toby Corkindale (tjc-wintrmute)]

Just thought I'd comment that the kernel 3.9.6 from the Mainline PPA seems to have resolved the problem for me on 13.04.

It's quite a relief!

[Joseph Salisbury (jsalisbury)]

@Jan, yes this fix will make it into the 3.8 kernel through the normal stable update process.

[Joseph Salisbury (jsalisbury)]

The fix for this bug will be released in the 3.8.13.3 kernel.

[Toby Corkindale (tjc-wintrmute)]

Aargh! Curses!
Mainline kernel 3.10.1 (from the PPA) has introduced this exact bug again!

[Toby Corkindale (tjc-wintrmute)]

Edit: Although I don't know how.. I just looked at the difference between 3.10.0 and 3.10.1 and there didn't seem to be anything in there for usb audio. The mainline PPA doesn't add patches, does it?

https://lkml.org/lkml/2013/7/13/115

[Toby Corkindale (tjc-wintrmute)]

Sorry to spam you all again, but just an update to the above comments.
Rolling back to 3.10.0 didn't fix the problem after all. What did was unplugging and replugging the USB Hub I had the USB Audio device plugged into. (Unplugging and replugging the audio device from the hub didn't help. Just unplugging the hub itself from the desktop.)

No idea how that could be causing an identical problem as the kernel issue was. It does seem like there's still some buggy handling of something in there somewhere.

[Tyson Tan (tysontan)]

No regression saw here. I'm using Linux Libre kernel 3.10.1 X64.

I think it is a bad idea to connect an USB DAC through a HUB, though. Even a mouse gets choppy from time to time in spite of being the only thing on a HUB. The last time I did this I was still using Windows 7 and it didn't work for me either. After that I only use HUB for USB storage device.

I guess USB HUB is not ideal for real time purpose because it increases DPC Latency. And USB DACs are generally very sensitive to DPC Latency. There might be changes in the kernel about CPU frequency control that caused your problem, which is a different issue of what we had discussed on this page.

[Alan Stern (stern)]

Toby: I'm sure whatever problem is caused by the hub is NOT identical to the original problem. It may have similar symptoms, but the underlying cause must be different. For example, it might be a bug in the hub itself.

Tyson: In theory, connecting a USB device through a hub should not affect any latency, DPC or other. Furthermore, in many cases there is no choice -- the design of the motherboard forces all non-high-speed devices to be routed to an on-board hub.

On the other hand, it is true that Linux's support for periodic transfers to low/full-speed USB devices is more robust in the UHCI and OHCI drivers than in the EHCI driver. This means that if your motherboard has a UHCI or OHCI controller, your DAC (or mouse!) is likely to work more reliably if plugged directly into the motherboard than if connected through a USB-2 hub. Using an old USB-1.1 hub should be about as good as going directly to the motherboard.

[Toby Corkindale (tjc-wintrmute)]

Hi Alan, Tyson,
I agree, my comment about this issue being a regression is definitely incorrect, and it's some kind of other issue.

However it is interesting that the symptoms I received really were identical to those presented by the original bug.
It sounds like there's a bug somewhere else that ends up trashing the async transfers. Ah well, for now I just know to disconnect the hub if it happens again.

Cheers,
Toby

[Welly Wu (wellywu)]

So, I'm using Ubuntu 13.04 64 bit and I have this:

wellywu@System76:/etc/pulse$ uname -r
3.8.0-27-generic

When is this going to be fixed?

I have a HRT MicroStreamer asynchronous USB DAC and headphone amplifier. I downloaded and installed Clementine Development from the PPA and I set ALSA sink to hw:1,0 output and I get crackling sounds when playing 88.2 and 96 kHz high resolution FLAC files.

[Andrejs Hanins (ahanins)]

Hi all, sorry for bothering, but I'm upgraded to latest Ubuntu 13.10 and the bug is still there, despite the fact fix was available few months ago. Is it expected situation?
Thanks.

[Tim Richardson (tim-richardson)]

13.04 is ok for me.
On 09/11/2013 10:05 pm, "Andrejs Hanins" <email address hidden> wrote:

> Hi all, sorry for bothering, but I'm upgraded to latest Ubuntu 13.10 and
> the bug is still there, despite the fact fix was available few months ago.
> Is it expected situation?
> Thanks.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1136110
>
> Title:
> USB Audio Codec choppy playback
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110/+subscriptions
>

[Tyson Tan (tysontan)]

@Andrejs
I'm using Trisquel 6.0 (Ubuntu 12.04 based) + Linux-libre 3.11.x / 3.12.0, it works fine for me.

[Alan Stern (stern)]

On Sat, 9 Nov 2013, Andrejs Hanins wrote:

> Hi all, sorry for bothering, but I'm upgraded to latest Ubuntu 13.10
> and the bug is still there, despite the fact fix was available few
> months ago. Is it expected situation?

Maybe you are seeing a different bug.

[Andrejs Hanins (ahanins)]

@Alan
At least, the distorted sound I hear is very similar to the original description and the patch provided here does help me. I'm very confused, because even the 3.9.6 kernel from ppa, which contains the fix does not help me.

What I'll do is to compile several versions of kernel with and without a patch to have an absolutely clear experiment and report here.

[Andrejs Hanins (ahanins)]

@Alan
To my surprise, the patch committed to the official Linux repo (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fdc03438f53a00294ed9939eb3a1f6db6f3d8963) is very different from the patch attached to this bug report (https://launchpadlibrarian.net/140553725/ehci-split-bugs). Why is it so? I guess, this a the reason why my USB async DAC still does not work with the officially fixed kernel and works with this local patch. I'm looking forward to resolve this situation and provide any additional debug info if needed. And I don't use USB Hub. Also the my locally compiled patched 3.9.4 Kernel has been working flawlessly with my Arcam USB Dac (r-dac)for half a year without any single issue.

[Toby Corkindale (tjc-wintrmute)]

I thought I should chip in to confirm that I still get occasional issues with my USB DAC, even on the current Saucy 3.11.0-12 kernel. The symptoms are identical to those that were occurring prior to the patch, however now they usually resolve by unplugging and replugging the DAC, whereas prior to the patch they never resolved.

I'm thinking there's still something not-quite-right in the kernel handling of these async audio devices. (Or possibly, these async audio devices don't always obey the USB spec perfectly in some way?)

[Alan Stern (stern)]

Andrejs:

If you read comments #118 and #121, you would understand why the kernel's revert is different from the patch attached to comment #118.

There is another commit currently queued for the 3.13 kernel release:

   https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit?id=976b6c064a957445eb0573b270f2d0282630e9b9

You might find that it helps your system. If it doesn't, please follow the debugging procedure described in comments #82, 90, 105, and 111.

[Andrejs Hanins (ahanins)]

Alan, finally I've found time and compiled mainline kernel from 15 of November (which includes the merge from tiwai branch) and I'm pleased to say that sound choppiness of my setup with Arcam rDAC has gone! Can't reproduce it whatsoever. Sound it flawless. So thanks a lot for your efforts, and I'll wait for official 3.13 release while sitting on custom compiled kernel. Not the first time I'm doing it, hehe :)

[mp (m-p)]

Still present for me in 3.11.0-12-generic.

On 17/11/13 14:32, Andrejs Hanins wrote:
> Alan, finally I've found time and compiled mainline kernel from 15 of
> November (which includes the merge from tiwai branch) and I'm pleased to
> say that sound choppiness of my setup with Arcam rDAC has gone! Can't
> reproduce it whatsoever. Sound it flawless. So thanks a lot for your
> efforts, and I'll wait for official 3.13 release while sitting on custom
> compiled kernel. Not the first time I'm doing it, hehe :)
>

[a! (a-guenther)]

Think I have similar problems using my Audiolab 8200 CD with the latest Kubuntu (Kernel 3.11.0-14).

Described my problem here: http://ubuntuforums.org/showthread.php?t=2190729 , but got no useful help, and found now this bug report. Please let me know if I can do something what would help the debugging, beside the informations in the link...

[netsuso (netsuso)]

Alan,

I have an asynchronous DAC (HRT microStreamer) and I had the problem described in this bug with current kernel releases when setting the output to 88.2 or 96 KHz (just as a side note, it only happened with ehci ports, it worked correctly with xhci ports)

I've just tried 3.13rc6 which includes your commit to improve the buffering and it works perfectly!! No more crackling even at 96/24.

So it's fixed for me, thanks a lot for your time and your effort!! :)

[gmz (gamax99)]

I have an laptop Acer and an Asus Xonar U7 with asynchronus USB Audio CM6632A. I'v tried this patches, but clicks was still here, with different kernel version. I'v started unloading kernel modules and after unloading acer-wmi clicks disapear.
Also nvidia's GPU powermizer frequency shift makes klicks sometimes. Setting constant GPU frequency fix this.
After blacklisting acer-wmi and setting constatn GPU freq. clicks completly disapear, even during kernel compill with 100% cpu load.

[Mark Rich (sir-marky)]

I have the arcam mwave device mentioned above.

I am using 13.10 with kernel 3.11.0-17-generic as part of the normal update procedure but the problem is still present.

I am uncertain how to apply the fix mentioned above (still very green when it comes to kernel rebuilds).
How can I resolve?

[a! (a-guenther)]

@mark: since i have the same problem (see #158) and am also unexperienced with kernel installations, I just wait now until the kernel 3.13 is in the package updates, I hope at latest with 14.04, so in 2 months...

or is there anywhere a simple manual how to do this update? which kernel will be in 14.04? or will be an kernel-update before?

[Mark Rich (sir-marky)]

Has anyone tested with the upcoming 14.04 release to see if the problem is still there?
I still have an expensive unused DAC waiting for a fix.

[Mark Rich (sir-marky)]

So I patiently waited for weeks until the release of 14.04 with its 3.13 kernel and the problem remains.

Did the patch not get integrated into the final release?

If not, why and how can I do it myself - in easy steps please!

I still cannot use my DAC without the crackles and pops. :-(

[Mark Rich (sir-marky)]

Does anyone read this anymore or am I yelling at the wind?

[mp (m-p)]

I am here. Hearing you.

On 21/04/14 11:46, Mark Rich wrote:
> Does anyone read this anymore or am I yelling at the wind?
>

[Mark Rich (sir-marky)]

The homePC/Server I built isn't a year old yet. I cannot justify replacing motherboard, RAM and CPU just for a single problem. I am using a 3770K on an ASUS P8Z-77v-Deluxe motherboard. Nothing about my rig is cheap sadly. :-(

[Phil C (jellyandicecream)]

Mark,

I've just had the same problem on Gentoo with a new (and rather expensive) DAC. With the 3.13 and 3.14 kernels it sounds like a bowl of Rice Krispies - snap, crackle and pop.

BUT! After reading this bug report I tried the latest 3.4 kernel (3.4.87) and that works perfectly. It would be nice to track down the proper fix, but at least we can listen to some nice music in the meantime.

[Mark Rich (sir-marky)]

>>

Mark,

I've just had the same problem on Gentoo with a new (and rather expensive) DAC. With the 3.13 and 3.14 kernels it sounds like a bowl of Rice Krispies - snap, crackle and pop.

BUT! After reading this bug report I tried the latest 3.4 kernel (3.4.87) and that works perfectly. It would be nice to track down the proper fix, but at least we can listen to some nice music in the meantime.
-----

I have just added a QED Bluetooth receiver to my sound system to allow me to stream my music without the rice krispies effect.
It's not a solution, but a fudge and work around until someone can help fix it. It doesn't sound as good and it chops off the top end frequencies but it's something. :-(

I tried a fresh installation of 14.04, in case of any legacy issues, files and configs from the 13.10 installation, but alas the same problems remained.

I did consider using openSUSE or another flavour of Linux too. I guess with your test of Gentoo, I can put it to one side.

[Alan Stern (stern)]

Mark, Phil, and others:

This problem is not going to get solved any time soon. It requires a substantial rewrite of a large portion of the ehci-hcd driver,, which would itself take many months, and I have other things to work on.

In theory you can get around the problem by buying an add-on PCI USB card and plugging the audio device into that card instead of into the motherboard's USB ports. Of course, this isn't practical for laptops and it has other obvious disadvantages.

If anybody feels like doing the work to fix up ehci-hcd, I'll be happy to provide advice and oversee their efforts.

[Mark Rich (sir-marky)]

Your suggestion does not work for me.

I have a USB PCI card installed to my computer alongside my motherboard USB ports. I have already tried the Arcam device on its ports with the same results when trying to isolate the cause previously.

[Alan Stern (stern)]

You know, if would help a lot if you provided some concrete data instead of just saying "it doesn't work". For example, what shows up in the dmesg log when you plug the audio device into the PCI card? If you collect a usbmon trace showing a noise-filled session, what do you get (see comments #72-#53 and also comment #82).

[Mark Rich (sir-marky)]

Apologies for being vague. I do not know how to get the information you need to help identify the problem. The comment numbers you suggested do not help me. I am still uncertain of my way around the lower levels of Linux.

Please tell me how to get the information you need.

[Alan Stern (stern)]

Do this: After plugging the audio device into the PCI card, run the "dmesg" command and attach the output to this bug report.

Did you read comment #72 in this bug report? Follow the intructions in the URL mentioned in that comment.

[Mark Rich (sir-marky)]

I have no idea if I have done what you desire correctly - given it's my first attempt to do so, however I hope the following will be helpful.

markrich@markys-home-pc:~$ lsusb
Bus 002 Device 005: ID 18d1:4ee1 Google Inc. Nexus 4
Bus 002 Device 004: ID 046d:0825 Logitech, Inc. Webcam C270
Bus 002 Device 003: ID 07b5:0317 Mega World International, Ltd
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 009 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 010 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 008 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 006: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 001 Device 007: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 001 Device 003: ID 0b05:17b5 ASUSTek Computer, Inc.
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 004: ID 0c56:0003 Billion Bright, Ltd <---------------------------- THIS IS THE ARCAM USB DAC DEVICE
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
markrich@markys-home-pc:~$

Linux markys-home-pc 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Result of DMESG upon inserting the device to the computer.

[12577.154663] usb 3-4: USB disconnect, device number 3
[12581.537084] usb 3-4: new full-speed USB device number 4 using xhci_hcd
[12582.385769] usb 3-4: New USB device found, idVendor=0c56, idProduct=0003
[12582.385774] usb 3-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[12582.385777] usb 3-4: Product: ARCAM Wireless Audio
[12582.385779] usb 3-4: Manufacturer: ARCAM
[12582.395414] 4:1:1: cannot get freq at ep 0x1
[12582.417913] 4:1:1: cannot get freq at ep 0x1
[12582.420866] 4:1:1: cannot get freq at ep 0x1
[12582.437893] 4:1:1: cannot get freq at ep 0x1
[12582.440824] 4:1:1: cannot get freq at ep 0x1
[12582.448387] 4:1:1: cannot get freq at ep 0x1
[12582.451144] 4:1:1: cannot get freq at ep 0x1

These last repeating lines seem to crop up a lot on reports of this problem as I have been searching around Google for answers.

T: Bus=03 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=0c56 ProdID=0003 Rev= 1.10
S: Manufacturer=ARCAM
S: Product=ARCAM Wireless Audio
C:* #Ifs= 2 Cfg#= 1 Atr=00 MxPwr= 20mA
I:* If#= 0 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=00 Driver=snd-usb-audio
I:* If#= 1 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=00 Driver=snd-usb-audio
I: If#= 1 Alt= 1 #EPs= 2 Cls=01(audio) Sub=02 Prot=00 Driver=snd-usb-audio
E: Ad=01(O) Atr=05(Isoc) MxPS= 585 Ivl=1ms
E: Ad=81(I) Atr=01(Isoc) MxPS= 3 Ivl=1ms

This information comes from, cat /sys/kernel/debug/usb/devices

I played a sound file and outputted the results (I think) to the a...

[Alan Stern (stern)]

Was this dmesg taken after you plugged the device into the add-on PCI card? It shows that the device is connected to a USB-3 port.

That's the reason for your problems; the support in Linux for isochronous transfers over USB-3 is buggy. Try plugging the device into a USB-2 port instead.

[Mark Rich (sir-marky)]

I will do so, however the problem is the same for both USB2 and USB3 ports. I have tried them all in the past on the three controllers (ASMEDIA, NEC and Intel).

[Mark Rich (sir-marky)]

[ 3379.830961] usb 3-4: USB disconnect, device number 2
[ 3394.173420] usb 2-1.5: new full-speed USB device number 6 using ehci-pci
[ 3394.973170] usb 2-1.5: New USB device found, idVendor=0c56, idProduct=0003
[ 3394.973176] usb 2-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 3394.973178] usb 2-1.5: Product: ARCAM Wireless Audio
[ 3394.973181] usb 2-1.5: Manufacturer: ARCAM
[ 3394.982917] 6:1:1: cannot get freq at ep 0x1
[ 3395.005298] 6:1:1: cannot get freq at ep 0x1
[ 3395.008167] 6:1:1: cannot get freq at ep 0x1
[ 3395.518273] 6:1:1: cannot get freq at ep 0x1
[ 3395.521167] 6:1:1: cannot get freq at ep 0x1
[ 3396.020796] 6:1:1: cannot get freq at ep 0x1
[ 3396.023791] 6:1:1: cannot get freq at ep 0x1

[Alan Stern (stern)]

Have you tried an add-on PCI USB-2 card? (The lsusb output suggests you don't.) That's the combination most likely to work. If you can do that, attach the corresponding usbmon trace.

If you don't have any USB-2 ports on the PCI card, attach a usbmon trace using a USB-2 port on the motherboard.

[Mark Rich (sir-marky)]

The device is now plugged into a USB port on the motherboard. I will do a USBMON trace for you later. I will need to buy another PCI USB card from eBay or other to provide another set of USB ports, however I'm using only half of those I presently have so will be overflowing with them.. :-/

[Mark Rich (sir-marky)]

I have attached a new report according to wishes from the device playing audio through a separate PCI USB PCIe device. The file is 2.mon.out.

The rice crispies sound is still present through this device too.

[Alan Stern (stern)]

What about the dmesg output for when you plugged in the audio device?

The information in the usbmon trace suggests that the device was plugged into a USB-3 port, not into the USB-2 PCI card.

[Mark Rich (sir-marky)]

This is the result of the output from dmesg.

[10633.605645] usb 9-2: USB disconnect, device number 2
[10639.410777] usb 9-2: new full-speed USB device number 3 using xhci_hcd
[10640.279483] usb 9-2: New USB device found, idVendor=0c56, idProduct=0003
[10640.279488] usb 9-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[10640.279491] usb 9-2: Product: ARCAM Wireless Audio
[10640.279493] usb 9-2: Manufacturer: ARCAM
[10640.308472] 3:1:1: cannot get freq at ep 0x1
[10640.360464] 3:1:1: cannot get freq at ep 0x1
[10640.366589] 3:1:1: cannot get freq at ep 0x1
[10640.392456] 3:1:1: cannot get freq at ep 0x1
[10640.399559] 3:1:1: cannot get freq at ep 0x1
[10640.428447] 3:1:1: cannot get freq at ep 0x1
[10640.434574] 3:1:1: cannot get freq at ep 0x1

The USB sound device is plugged into the newly purchased USB2 PCIe card.

[Alan Stern (stern)]

I hate to say this, but the "xhci_hcd" in the second line means that the port is USB-3, not USB-2.

[Mark Rich (sir-marky)]

This is the result of the output from dmesg.

[10633.605645] usb 9-2: USB disconnect, device number 2
[10639.410777] usb 9-2: new full-speed USB device number 3 using xhci_hcd
[10640.279483] usb 9-2: New USB device found, idVendor=0c56, idProduct=0003
[10640.279488] usb 9-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[10640.279491] usb 9-2: Product: ARCAM Wireless Audio
[10640.279493] usb 9-2: Manufacturer: ARCAM
[10640.308472] 3:1:1: cannot get freq at ep 0x1
[10640.360464] 3:1:1: cannot get freq at ep 0x1
[10640.366589] 3:1:1: cannot get freq at ep 0x1
[10640.392456] 3:1:1: cannot get freq at ep 0x1
[10640.399559] 3:1:1: cannot get freq at ep 0x1
[10640.428447] 3:1:1: cannot get freq at ep 0x1
[10640.434574] 3:1:1: cannot get freq at ep 0x1

The USB sound device is plugged into the newly purchased USB2 PCIe card.

[Mark Rich (sir-marky)]

I have asked the retailer to take back the card I have purchased. It is of no use to me if Linux is reporting it as USB3 and not USB2.

[Alan Stern (stern)]

Just what I was going to suggest. Maybe you can find a true USB-2 card somewhere else.

You can try building a kernel with the attached (untested) patch. It is a partial fix for a bug in the xHCI driver, and it might solve your problem on the USB-3 ports.

[Mark Rich (sir-marky)]

I do not know how to apply the patch mentioned without guidance and instructions.

[Alan Stern (stern)]

There probably is a document somewhere on the Ubuntu web site explaining how to do this. (I don't know where, and I don't use Ubuntu.) Or maybe Joseph Salisbury can do it for you.

[Alan Stern (stern)]

I recently heard that USB audio works okay over USB-3 using xHCI controllers from NEC rather than Intel; see

   http://marc.info/?l=linux-usb&m=139958150312402&w=2

If you run "lspci", it will show the manufacturers for the xHCI controllers in your system.

[Mark Rich (sir-marky)]

This is the output from LSPCI. There is a mention of NEC USB 3 controller, however I have tried all the USB2 and USB3 ports on the machine previously without success.

markrich@markys-home-pc:~$ lspci
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor DRAM Controller (rev 09)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port (rev 09)
00:02.0 Display controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09)
00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04)
00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 (rev 04)
00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network Connection (rev 04)
00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04)
00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 (rev c4)
00:1c.4 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 5 (rev c4)
00:1c.6 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 7 (rev c4)
00:1c.7 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 8 (rev c4)
00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation Z77 Express Chipset LPC Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation 7 Series/C210 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04)
00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller (rev 04)
01:00.0 VGA compatible controller: NVIDIA Corporation GK104 [GeForce GTX 660 Ti] (rev a1)
01:00.1 Audio device: NVIDIA Corporation GK104 HDMI Audio Controller (rev a1)
03:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
04:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
05:00.0 PCI bridge: PLX Technology, Inc. PEX 8608 8-lane, 8-Port PCI Express Gen 2 (5.0 GT/s) Switch (rev ba)
06:01.0 PCI bridge: PLX Technology, Inc. PEX 8608 8-lane, 8-Port PCI Express Gen 2 (5.0 GT/s) Switch (rev ba)
06:04.0 PCI bridge: PLX Technology, Inc. PEX 8608 8-lane, 8-Port PCI Express Gen 2 (5.0 GT/s) Switch (rev ba)
06:05.0 PCI bridge: PLX Technology, Inc. PEX 8608 8-lane, 8-Port PCI Express Gen 2 (5.0 GT/s) Switch (rev ba)
06:06.0 PCI bridge: PLX Technology, Inc. PEX 8608 8-lane, 8-Port PCI Express Gen 2 (5.0 GT/s) Switch (rev ba)
06:07.0 PCI bridge: PLX Technology, Inc. PEX 8608 8-lane, 8-Port PCI Express Gen 2 (5.0 GT/s) Switch (rev ba)
06:08.0 PCI bridge: PLX Technology, Inc. PEX 8608 8-lane, 8-Port PCI Express Gen 2 (5.0 GT/s) Switch (rev ba)
06:09.0 PCI bridge: PLX Technology, Inc. PEX 8608 8-lane, 8-Port PCI Express Gen 2 (5.0 GT/s) Switch (rev ba)
09:00.0 SATA controller: ASMedia Technology Inc. A...

[Alan Stern (stern)]

You can find the correspondence between the PCI device list and the USB bus list by running

   grep . /sys/bus/usb/devices/usb*/serial

In addition to the NEC controller, your listing includes two EHCI (i.e., USB-2) controllers; they are the ones with "Enhanced" in the description. Any of those controllers ought to work okay for your audio.

[a! (a-guenther)]

Hi!
Finally I also upgraded to Kubuntu 14.04, and have also still the crackles. Since it is a very old Laptop, there are only USB 2.0 connectors, so for sure no USB-3.0 problem...

And: running on the same laptop daphile (which is a headless player based on Gentoo) works fine, without any problems. Wondering why it's fine with that one, but not Kubuntu...

So, let's see if I can help anything...

Here's my lsusb:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 003: ID 0451:8200 Texas Instruments, Inc.
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

So, the 5th is the DAC, a Audiolab 8200CD. (no other USB devices connected)

dmesg gives a lot of outputs, so only ones that differ while playback are:
[19545.228188] 3:2:1: cannot get freq at ep 0x1
[19545.231204] 3:2:1: cannot get freq at ep 0x1
[19549.621200] delay: estimated 265, actual 44
(all other lines are similar to: [19550.940214] status interrupt: 80 02)

Since I am also more a user then a linux pro: what prompts might be useful to narrow the problem down?

[Alan Stern (stern)]

Please read comment #172.

[a! (a-guenther)]

Ok, finally got the time. Attached is the output stream with some audible cracks, like explained above. Hope I did it right...

Not sure if the output of cat /sys/kernel/debug/usb/devices is of any interest, but here it is:

T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=0451 ProdID=8200 Rev= 1.60
S: Manufacturer=Lakewest Audio
S: Product=Audiolab 8200 Series
C:* #Ifs= 3 Cfg#= 1 Atr=c0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid
E: Ad=82(I) Atr=03(Int.) MxPS= 1 Ivl=32ms
I:* If#= 1 Alt= 0 #EPs= 1 Cls=01(audio) Sub=01 Prot=00 Driver=snd-usb-audio
E: Ad=83(I) Atr=03(Int.) MxPS= 2 Ivl=32ms
I:* If#= 2 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=00 Driver=snd-usb-audio
I: If#= 2 Alt= 1 #EPs= 2 Cls=01(audio) Sub=02 Prot=00 Driver=snd-usb-audio
E: Ad=01(O) Atr=05(Isoc) MxPS= 582 Ivl=1ms
E: Ad=81(I) Atr=11(Isoc) MxPS= 3 Ivl=1ms

[a! (a-guenther)]

Not sure if uploading my attachment worked right, got a confirmation, but can't find it in my comment. Used the "add attachment" below the comment field. If it is lost somewhere, I could upload it again.

[Alan Stern (stern)]

The usbmon trace contains a bunch of -63 error codes. 28 of them occurred during the 13-second trace. This code is documented to mean "During an OUT transfer, the Host Controller could not retrieve data system memory fast enough to keep up with the USB data rate".

In other words, the PCI bus in your old laptop was overloaded.

[a! (a-guenther)]

Thanks for looking into it!
But I wonder, if this should be an issue of my hardware, why I can use the same laptop with the same DAC without problems with daphile (http://www.daphile.com/ , a headless Gentoo-based player)? Shouldn't daphile have the same problems? Or is there a way to configure the PCI bus to get it working?

[Alan Stern (stern)]

I can't tell what's happening with daphile. Maybe it's simply a matter of how much network activity or disk activity or graphics activity is going on at the time. (Of course, storing a usbmon trace creates some disk activity of its own...)

You can check whether graphics is the issue by switching to a VT console while the audio is playing.

There is no way to reconfigure the PCI bus.

[mp (m-p)]

this bug persists for me, now on 3.11, just tried a live system again

(have tried every new Ubuntu, Mint and Debian distro since bug appeared)

does it help to submit data here?

[Michael MacEachern (maceach-b)]

I also am having terrible USB audio. Trying to just chill listening to the blues, and hear every minute, a pop or hiccup. If I switch to the onboard sound (even if SPDIF output), perfectly fine. My monitor's built in speakers are USB, and I'm about to just connect regular speakers to the built in sound output.

I've been having this problem for several years. (Since I bought this computer in 2008 to be exact).

[Michael MacEachern (maceach-b)]

I should note that running either Mac OS X or Windows, results in perfect audio. It's only ever been Linux with the problem. Though to be honest, after 6 years of unresolved USB audio, I've grown to just accept that this will never be fixed.

[Tim Passingham (tim-8aw3u04umo)]

I am on 14.04, 64 bit, a new Samsung laptop bought earlier this year.

Connecting via USB 2 or USB 3 to my Musical Fidelity M1 CLiC Async USB DAC gives the crackles and interruptions as described above (analogue or digital). When connected it is described as a PCM2706 Audio Codec Digital Stereo (IEC958). I have tried the Analogue and Digital configurations. Quite often Pulseaudio just stops and restarts.

Connecting via USB 2 or USB 3 to my Meridian Explorer Async USB DAC works fine.

On my old (2003) Sony Laptop, recently retired, it worked fine.

An extract from my syslog follows. I had just disconnected from the USB 3 port and connected to my USB 2 port. This is, whatever the log may say, not a USB 3 device or port.

WIll there really be no fix? It seems pretty fundamental for many Async USB DACs.

Dec 6 13:31:55 twpsamlinux kernel: [ 418.785848] HDMI ATI/AMD: no speaker allocation for ELD
Dec 6 13:33:20 twpsamlinux kernel: [ 503.543057] usb 5-1: USB disconnect, device number 2
Dec 6 13:33:29 twpsamlinux kernel: [ 512.148960] usb 3-1: new full-speed USB device number 2 using ohci-pci
Dec 6 13:33:29 twpsamlinux kernel: [ 512.316151] usb 3-1: New USB device found, idVendor=08bb, idProduct=2706
Dec 6 13:33:29 twpsamlinux kernel: [ 512.316173] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Dec 6 13:33:29 twpsamlinux kernel: [ 512.316185] usb 3-1: Product: USB Audio DAC
Dec 6 13:33:29 twpsamlinux kernel: [ 512.316195] usb 3-1: Manufacturer: Burr-Brown from TI
Dec 6 13:33:29 twpsamlinux kernel: [ 512.370306] input: Burr-Brown from TI USB Audio DAC as /devices/pci0000:00/0000:00:12.0/usb3/3-1/3-1:1.2/input/input12
Dec 6 13:33:29 twpsamlinux kernel: [ 512.370910] hid-generic 0003:08BB:2706.0002: input,hidraw0: USB HID v1.00 Device [Burr-Brown from TI USB Audio DAC ] on usb-0000:00:12.0-1/input2
Dec 6 13:35:01 twpsamlinux kernel: [ 604.390700] HDMI ATI/AMD: no speaker allocation for ELD
Dec 6 13:35:01 twpsamlinux kernel: [ 604.687996] HDMI ATI/AMD: no speaker allocation for ELD
Dec 6 13:35:01 twpsamlinux kernel: [ 604.987999] HDMI ATI/AMD: no speaker allocation for ELD
Dec 6 13:35:02 twpsamlinux kernel: [ 605.288020] HDMI ATI/AMD: no speaker allocation for ELD
Dec 6 13:35:02 twpsamlinux kernel: [ 605.588042] HDMI ATI/AMD: no speaker allocation for ELD

[Tim Passingham (tim-8aw3u04umo)]

Furthermore, I resurrected my old Sony laptop just to try and test this, with xubuntu 14.04, and it works OK. Being of 2003 vintage it's only just USB 2, let alone 3.

So it seems to me that there may be a problem with the USB 3 support misidentifying a USB 2 device in some fashion.

Can I force something in the udev rules somewhere?

[Andrejs Hanins (ahanins)]

@Tim Passingham, as I understood from Alan Stern in earlier posts, most modern computers emulate USB2 through USB3 root hub, so basically USB3 XHCI driver is used for all connected devices, and async usb audio support in XHCI driver is somewhat flawed.
I also had similar problem a year a so ago, but it disappeared since then (now on Ubuntu 14.10 Arcam R-DAC).

[Alan Stern (stern)]

Tim: This has nothing to do with USB-3. You can tell from the log:

> Dec 6 13:33:29 twpsamlinux kernel: [ 512.148960] usb 3-1: new full-speed USB device number 2 using ohci-pci

OHCI is strictly USB-1.1. However, you have not provided nearly enough useful information to tell what's going wrong. You didn't even say what version of the kernel you are using! -- let alone provide a usbmon trace like some of the other people contributing to this bug report.

[Tim Passingham (tim-8aw3u04umo)]

I assumed that since others had supplied so much detail I didn't need to supply any more. I was simply saying that this problem affects me as well (as I think was requested by an earlier post), and noting that on an older USB-2 only system I get no problems at all (and didn't have on previous versions of xubuntu). I thought that might be useful extra information.

I don't know enough about linux to know what to include, or how. I am just a user, not any form of expert. So I don't know what OHCI is, but when is says .../0/usb3/3-1... I assume that's what it means. More fool me.

Both laptops are on 14.04 xubuntu, fully up to date. If it really will help, I will try to read and understand all 200 items here and submit further data, but I didn't imagine I'd have anything new to contribute.

[Tim Passingham (tim-8aw3u04umo)]

Andrejas: You say "I also had similar problem a year a so ago, but it disappeared since then (now on Ubuntu 14.10 Arcam R-DAC)." Are you saying that the same DAC didn't work under 14.04 but does under 14.10? Has the problem therefore definitely been analysed and fixed in 14.10?

[Alan Stern (stern)]

On Sat, 6 Dec 2014, Tim Passingham wrote:

> I assumed that since others had supplied so much detail I didn't need to
> supply any more. I was simply saying that this problem affects me as
> well (as I think was requested by an earlier post),

What makes you think this is the same problem? It probably isn't,
since the problem that originally provoked this bug report has been
fixed. And so have some of the other problems raised later on in this
same bug report.

> and noting that on
> an older USB-2 only system I get no problems at all (and didn't have on
> previous versions of xubuntu). I thought that might be useful extra
> information.

I doubt that the age of the system is directly related.

> I don't know enough about linux to know what to include, or how. I am
> just a user, not any form of expert. So I don't know what OHCI is, but
> when is says .../0/usb3/3-1... I assume that's what it means. More fool
> me.
>
> Both laptops are on 14.04 xubuntu, fully up to date. If it really will
> help, I will try to read and understand all 200 items here and submit
> further data, but I didn't imagine I'd have anything new to contribute.

What is the output from uname -r? Also, see comment #172.

[Tim Passingham (tim-8aw3u04umo)]

To keep this brief - I'm an idiot. It's all my own fault. Sorry for wasting people's time reading my scribbles.

Now the longer version. I did some extensive tests, playing local music via VLC - OK. Remote server music via VLC and foobar (under wine) - Not OK. Internet music (Firefox, BBC radio streams) - Not OK. Ethernet vs Wi-Fi - no difference. I then looked at my notes for any modifications I might have made in the past, and there it was. I had changed the default pulse-audio bit rate in /etc/pulse/daemon.conf to suit another application using a different output device. My memory being what it is (age...) I had totally forgotten. Reverting to standard fixed the problem. I don't really understand why local music under VLC was OK and other's not, but no matter. The problem has gone away.

Now I shall go away and hide....

[a! (a-guenther)]

Just a short update:
Since my old computer brock down (more then 8 years old laptop), I have now a Thinkpad T450p. Running Kubuntu 14.10, as before my DAC is an Audiolab 8200CD. And this issue does not occur anymore, neither on the USB 2 nor USB 3 plug.
So might have been really an hardware issue somehow for me before.
Cheers!

[Kevin Beel (k-beel)]

Can someone explain how, if at all, these fixes flow through to other Linux versions like Fedora?

[Tyson Tan (tysontan)]

I thoroughly tested the patches when the bug happened to me before. The same kind of stuttering never happened again after the fix was released. I suppose the newer reports are not related to this bug. Please understand not all choppy audio has the same source.

You may troubleshoot over these things:
1) Turn off Wireless and Bluetooth. CSR Bluetooth adapters are more stable. Broadcom to my experience is very bad at this. Realtek wifi chips are kinda bad, too.
2) Do not use USB hub, or make sure it is sufficiently powered (>500mA per port, >2A DC adapter).
3) Make sure the playback samplerate is native of the device. Pulseaudio's SRC could introduce stuttering. If your DAC is 48K by default and you output 44.1K to Pulseaudio, it can chop things up.
4) Do not use aggressive power save options in your BIOS.
5) Try plug the DAC on USB2.0 only ports, not USB3.0 ports. Many USB3.0 ports are running on 3rd party chips.

Hope it helps!