USB Audio Codec choppy playback

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.

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/

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

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

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

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!

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.

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

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

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

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

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

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

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

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.

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!

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]

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.

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.

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

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.

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

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

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

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.

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.

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

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.

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

[ 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

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.

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

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

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

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

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

This is the result of the output from dmesg.

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

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

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

This is the result of the output from dmesg.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Please read comment #172.

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

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

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

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

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

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

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

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

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

There is no way to reconfigure the PCI bus.

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

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

does it help to submit data here?

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

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

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

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

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

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

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

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

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

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

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

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

Can I force something in the udev rules somewhere?

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

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

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

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

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

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

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

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

On Sat, 6 Dec 2014, Tim Passingham wrote:

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

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

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

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

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

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

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

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

Now I shall go away and hide....

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

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

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

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

Hope it helps!