Ubuntu

USB Audio Codec choppy playback

Reported by Tyson Tan on 2013-02-28
126
This bug affects 23 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Medium
Unassigned

Bug Description

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

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.

Changed in linux (Ubuntu):
status: New → Incomplete
tags: added: quantal

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/

Changed in linux (Ubuntu):
importance: Undecided → Medium
Tyson Tan (tysontan) wrote :

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

apport information

tags: added: apport-collected package-from-proposed running-unity third-party-packages
description: updated

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

Changed in linux (Ubuntu):
status: Incomplete → Confirmed

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) on 2013-03-14
summary: - Asynchronous USB DAC cracking sound in Linux kernel 3.5.0.26
+ Asynchronous USB DAC cracking sound in Linux kernel 3.5.0.26 and later
description: updated
Tyson Tan (tysontan) on 2013-03-14
description: updated
Tyson Tan (tysontan) on 2013-03-14
description: updated
summary: - Asynchronous USB DAC cracking sound in Linux kernel 3.5.0.26 and later
+ USB Audio Codec jerky playback (crackling noise)
tags: added: kernel-bug-exists-upstream

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) on 2013-03-14
tags: added: raring
tags: added: audio usb
Tyson Tan (tysontan) on 2013-03-15
tags: added: kernel-bug usb-audio
Tyson Tan (tysontan) on 2013-03-17
description: updated
Tyson Tan (tysontan) wrote :

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.

description: updated
description: updated
Tyson Tan (tysontan) wrote :

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

description: updated
Tyson Tan (tysontan) wrote :

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

description: updated
Tyson Tan (tysontan) wrote :

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

summary: - USB Audio Codec jerky playback (crackling noise)
+ USB Audio Codec choppy playback
Jan (ya-me) wrote :

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) wrote :

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

description: updated
Tyson Tan (tysontan) wrote :

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

description: updated
Jan (ya-me) wrote :

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) wrote :

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

Tyson Tan (tysontan) wrote :

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) wrote :

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!

tags: added: kernel-da-key

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) wrote :

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) on 2013-03-23
description: updated
description: updated
description: updated
Tyson Tan (tysontan) wrote :

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) wrote :

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

description: updated
Jan (ya-me) wrote :

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

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)

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) wrote :

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

description: updated
Tyson Tan (tysontan) wrote :

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

description: updated
Joseph Salisbury (jsalisbury) wrote :

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) wrote :

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) wrote :

>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) wrote :

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.

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.

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

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

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

> 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) wrote :

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

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.

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
>

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

tags: added: performing-bisect

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) wrote :

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) wrote :

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

Joseph Salisbury (jsalisbury) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

I have tested the following commit:
b09a61cc0bc2a7151f4ab652489e85253d5d0175

This kernel is not affected by the bug.

Jan (ya-me) wrote :

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) wrote :

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) wrote :

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

Joseph Salisbury (jsalisbury) wrote :

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) wrote :

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

Tyson Tan (tysontan) wrote :

>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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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

Alan Stern (stern) 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?

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) wrote :

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) wrote :

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.

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) wrote :

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.

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 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) wrote :

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) wrote :

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) wrote :

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

Joseph Salisbury (jsalisbury) wrote :

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) wrote :

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)

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) wrote :

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

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) wrote :

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

Jan (ya-me) wrote :

For me neither live or installed version works.

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) wrote :

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

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

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) wrote :

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

Joseph Salisbury (jsalisbury) wrote :

@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) wrote :

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

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.

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

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) wrote :

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.

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.

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

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) wrote :

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

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

Alan Stern (stern) wrote :

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) wrote :

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?

tags: added: patch

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

attached: periodic.txt

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

Alan Stern (stern) wrote :

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) wrote :

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

tags: removed: performing-bisect
Jan (ya-me) wrote :

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

mp (m-p) wrote :

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) wrote :

@ Joseph Salisbury

with this kernel, the problem still exists for me:

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

Andrejs Hanins (ahanins) wrote :

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) wrote :

@ Andrejs Hanins:

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

thanks!

Andrejs Hanins (ahanins) wrote :

@ 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) wrote :

@ 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) wrote :

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) wrote :

Alan, thanks for all the help with this issue!

Alan Stern (stern) wrote :

Thanks to Tyson and Tim for all their testing.

Tyson Tan (tysontan) wrote :

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) wrote :

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) wrote :

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) wrote :

Will it ever get into mainline ubuntu 3.8?

jazztickets (jazztickets) wrote :

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.

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) wrote :

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

Joseph Salisbury (jsalisbury) wrote :

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

Changed in linux (Ubuntu):
status: Confirmed → Fix Committed

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

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

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) wrote :

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) wrote :

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.

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

Changed in linux (Ubuntu):
status: Fix Committed → Fix Released
Welly Wu (wellywu) wrote :

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

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) wrote :

@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) wrote :

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) wrote :

@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) wrote :

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

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) wrote :

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

mp (m-p) wrote :

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) wrote :

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

Changed in linux (Ubuntu):
assignee: nobody → a! (a-guenther)
a! (a-guenther) on 2013-12-09
Changed in linux (Ubuntu):
assignee: a! (a-guenther) → nobody
netsuso (netsuso) wrote :

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) wrote :

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) wrote :

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) wrote :

@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) wrote :

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) wrote :

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) wrote :

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

mp (m-p) wrote :

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) wrote :

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) wrote :

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) wrote :

>>

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :
Download full text (3.2 KiB)

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

Read more...

Alan Stern (stern) wrote :

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) wrote :

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) wrote :

[ 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) wrote :

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) wrote :

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.. :-/

To post a comment you must log in.