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.

tags: added: performing-bisect
tags: added: patch
tags: removed: performing-bisect
Changed in linux (Ubuntu):
status: Confirmed → Fix Committed
100 comments hidden view all 180 comments

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

Displaying first 40 and last 40 comments. View all 180 comments or add a comment.