Bug 202455

Summary: Crackling audio over USB-C monitor
Product: Drivers Reporter: David Bazile (david)
Component: Sound(ALSA)Assignee: Jaroslav Kysela (perex)
Status: NEW ---    
Severity: normal CC: chris.snell, foobars.droid, james, jonah.aberle, krnl, lee.hambley, matiaslaporte, miggles, mopoj71494, noah.worky, rhiobet, tiwai, z411
Priority: P1    
Hardware: Intel   
OS: Linux   
Kernel Version: 4.20.3 Subsystem:
Regression: No Bisected commit-id:
Attachments: alsa-info-output (after several attempts to troubleshoot).txt
alsa-info.sh output (after reboot)
Output of alsa-info.sh
alsa-info output
lspci -v output
dmesg output after boot

Description David Bazile 2019-01-30 01:36:10 UTC
Created attachment 280863 [details]
alsa-info-output (after several attempts to troubleshoot).txt

When connected to a monitor via USB-C, sound comes through but is accompanied by persistent loud crackling every 100-200ms.

I'm using the following tests to reproduce this issue:
  - Executing `aplay -D plughw:0,7 /usr/share/sounds/alsa/Front_Center.wav`
  - Media on local disk
  - Spotify
  - YouTube


The hardware I'm using is:
  - Samsung S27H850 Monitor w/ USB-C
  - Lenovo Thinkpad X1 Carbon 6gen (Fedora 29; kernel 4.20.3)
  - USB-C cable (mid-grade)


Issue also occurs connecting the same monitor to the following machines:
  - Dell XPS 15 9575 (Ubuntu 18.04; unsure which kernel)
  - Lenovo Thinkpad E480 (Fedora 28; kernel 4.20.3)


I originally filed a bug with PulseAudio but was directed here after further diagnostics -- https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/625

Lastly, I'm not familiar at all with troubleshooting audio driver problems, particularly those without noisy errors.  In other words, I'm basically using sticks and stones to diagnose/troubleshoot so if anyone has any pointers I'm all ears. :)
Comment 1 David Bazile 2019-01-30 01:45:02 UTC
Created attachment 280865 [details]
alsa-info.sh output (after reboot)
Comment 2 C Snell 2019-03-13 18:11:11 UTC
I've been experiencing similar issues with my JDS Labs UAC1 USB DAC.  This is regular old USB 2.  The problem is intermittent.  I've tested the speakers and DAC on my Apple iMac with macOS and the problem doesn't occur with that combination.  I've also tested the speakers plugged into the regular built-in sound card on this Linux PC and the audio is just fine.  It's only present whenh the USB DAC is used under Linux.

Like you, the problem happens with many different audio sources: cmus, YouTube, Spotify, etc.  

The problem sounds like audio being played at a very poor bitrate.  It's crackly, muddy, and poppy.

For me, the problem started around a week ago when I was running kernel 4.20.14 or so, but is also present in 5.0 kernels.  This doesn't align with David's report above so it may be a different issue entirely or it may be a non-kernel issue.
Comment 3 C Snell 2019-03-13 18:12:58 UTC
Created attachment 281813 [details]
Output of alsa-info.sh
Comment 4 Noah Worky 2019-04-16 22:26:34 UTC
I have the same issue as David.

Lenovo T480 + Samsung LC34H890WJUXEN

Tried mint/fedora issue is identical.
However Windows 10 October 2018 works flawlessly.

Like David, I Disabled pulse audio and confirmed with aplay selecting different HW:X,Y devices. 

This issue only occurs over usb-c. The same hardware communicating via HDMI does not exhibit the persistent static crackling.

The static crackling persists for a few seconds after the sound output is complete and stop (I'm guessing) when the device is closed.
Comment 5 Noah Worky 2019-04-16 23:31:19 UTC
Created attachment 282353 [details]
alsa-info output
Comment 6 Noah Worky 2019-04-16 23:34:22 UTC
Created attachment 282355 [details]
lspci -v output
Comment 7 Noah Worky 2019-04-16 23:34:52 UTC
Created attachment 282357 [details]
dmesg output after boot
Comment 8 valer 2020-05-26 06:21:40 UTC
Confirming issue.

Setup:
- Dell U2520D monitor
- Focusrite Scarlett 18i8 plugged in the monitor
- T460s connected via USB-C to monitor (power, displayport, usb)
- Sturdy USB-C cable shipped with monitor

While running `stress -c 1`, the crackling dissappears.

Also tested cpu throttling but it's unrelated: `cpupower frequency-set -g performance`.

------------------

After an arbitrary usb-c plug/unplug + standby/wakeup cycle the crackling dissappears. No other hints on why.

Nothing noticed in dmesg (sound nor usb related).
Comment 9 Pierre Jeanjean 2020-09-26 09:14:45 UTC
Just want to add that I have the exact same issue, with a Thinkpad T580.

Whenever I'm using a USB-C DP dock, audio starts crackling, and using the stress command temporarily fixes the issue.
Comment 10 Morgan Grubb 2020-12-10 05:31:32 UTC
Confirming issue on a Dell XPS 9500 on Neon (Ubuntu 20.04) with audio playing through an OWC Thunderbolt 3 dock - if I run `stress -c 1` or set the cpu governor to maximum performance the issue goes away. The issue is not present on Windows.
Comment 11 Takashi Iwai 2021-01-08 14:37:28 UTC
Please avoid adding just "me-too" comments.  The original report was about the onboard HD-audio, hence it has nothing to do with USB-audio or the dock stuff.  For other hardware, simply open another bug report.  Thanks.
Comment 12 Takashi Iwai 2021-01-08 14:40:51 UTC
Erm, scratch that, a wrong bug entry.

The problem with USB type-C dock can come from various reasons: it could be a firmware bug (yes, it has its own firmware to be updated), it could be a graphics driver problem and it could be a USB controller problem.  And finally it could be a lack of the audio implicit feedback support.  In the last case, the latest 5.11-rc kernel might improve things -- or it might get improved if you enable the implicit_fb option of snd-usb-audio module.
Comment 13 David Bazile 2021-01-09 01:26:47 UTC
UPDATE:

Two months ago, I replaced the Samsung monitor with a Dell U2721DE. Audio via USB-C on the new monitor doesn't crackle at all. Same computer (running whatever the latest kernel available for Fedora 31 was at the time), just a different monitor.

Two differences to note with the two monitors:

1. The Samsung's volume was adjustable while the Dell's volume is fixed
2. The Samsung delivered 45W of charge while the Dell delivers 65W
Comment 14 Matias Laporte 2021-09-29 14:26:26 UTC
I am having the same issue. Indeed `stress -c 1` fixes it (I know it's not ideal, but at least it makes listening to music enjoyable :) ).

My setup:
* Thinkpad T490
* Lenovo Thinkpad Thunderbolt 3 Dock Gen 2.
* Ubuntu 21.04 with kernel 5.11.0-37
Comment 15 Mopoj 2021-11-16 21:22:48 UTC
Same issue here.
Crackling, additional sounds like washing.
Begins randomly: in a couple of seconds to couple of minutes.
If I connect the dock before booting then the issue seems to disappear until I reconnect the dock.
The issue is gone while running `stress -c 1`.

My setup:
* Dell XPS 15 (7590)
* Dell WD19TB (Thunderbolt Docking Station)
* Fedora 35 with kernel 5.14.17-301
Comment 16 Lee Hambley 2022-01-15 18:41:35 UTC
Same problem here (apparently) with a :

- Dell XPS 13" (9380)
- Dell WD19TB (Thunderbolt3 (TB)
- Linux Fedora 5.15.14-200.fc35.x86_64 
- Scarlet 2i2 external sound device driving monitor speakers, and providing mic input.

I also have input defects (keyboard feels "sticking" like maybe keyup events aren't sending reliably) via the same dock/USB.

Confirming that running `stress -c 1` solves the problem as long as it is running with the output:

```
$ stress -c 1
stress: info: [6062] dispatching hogs: 1 cpu, 0 io, 0 vm, 0 hdd
```

dmesg shows a lot of this:

```
[  913.916898] usb 5-2.3.2.4.2: reset low-speed USB device number 13 using xhci_hcd
[  915.652722] usb 5-2.3.2.4.2: reset low-speed USB device number 13 using xhci_hcd
[  917.868677] usb 5-2.3.2.4.2: reset low-speed USB device number 13 using xhci_hcd
[  919.532761] usb 5-2.3.2.4.2: reset low-speed USB device number 13 using xhci_hcd
[ 1062.342310] retire_capture_urb: 440 callbacks suppressed
[ 1064.170967] usb 5-2.3.2.4.2: reset low-speed USB device number 13 using xhci_hcd
[ 1066.602960] usb 5-2.3.2.4.2: reset low-speed USB device number 13 using xhci_hcd
[ 1067.361345] retire_capture_urb: 1367 callbacks suppressed
[ 1072.366417] retire_capture_urb: 1507 callbacks suppressed
[ 1075.563859] usb 5-2.3.2.4.2: reset low-speed USB device number 13 using xhci_hcd
[ 1077.405569] retire_capture_urb: 975 callbacks suppressed
[ 1079.458878] usb 5-2.3.2.4.2: reset low-speed USB device number 13 using xhci_hcd
[ 1082.408598] retire_capture_urb: 840 callbacks suppressed
[ 1087.442599] retire_capture_urb: 464 callbacks suppressed
[ 1092.449547] retire_capture_urb: 1115 callbacks suppressed
```

Clearing dmesg whilst `stress -c 1` is running leaves it clean, however as soon as stress is stopped then dmesg reports the following:

```
➜  ~ dmesg
➜  ~ dmesg
➜  ~ dmesg
➜  ~ dmesg
[ 1155.835925] retire_capture_urb: 77 callbacks suppressed
➜  ~ dmesg
[ 1155.835925] retire_capture_urb: 77 callbacks suppressed
➜  ~ dmesg
[ 1155.835925] retire_capture_urb: 77 callbacks suppressed
[ 1159.945978] usb 5-2.3.2.4.2: reset low-speed USB device number 13 using xhci_hcd
➜  ~ dmesg
[ 1155.835925] retire_capture_urb: 77 callbacks suppressed
[ 1159.945978] usb 5-2.3.2.4.2: reset low-speed USB device number 13 using xhci_hcd
[ 1160.950382] retire_capture_urb: 1386 callbacks suppressed
➜  ~ dmesg
[ 1155.835925] retire_capture_urb: 77 callbacks suppressed
[ 1159.945978] usb 5-2.3.2.4.2: reset low-speed USB device number 13 using xhci_hcd
[ 1160.950382] retire_capture_urb: 1386 callbacks suppressed
```
Comment 17 Jonah Aberle 2022-03-20 21:57:57 UTC
I've been working on resolving this issue. After switching from Manjaro Linux (XFCE) to NixOS (Gnome) I found that my USB audio was crackling.

My Lenovo ThinkPad T480 is connected to a ThinkPad Thunderbolt 3 Gen 2 dock, which my USB audio interface is then connected to.

I eventually found that for some reason if I connect the dock to a standard USB C port, the issue resolves (but I lose Thunderbolt functionality). Then I found that any audio source whatsoever connected downstream from the thunderbolt port, even a USB-C headphone adapter, was crackling.

I saw this post. `stress -c 1` did seem to resolve the issue. A lot of other forum posts seemed to mention issues with power savings causing sampling freq issues... That's when it clicked!

**Gnome's power profiles daemon is the source of this issue**

I disabled it and enabled TLP instead. My issue is finally resolved.

Thanks for the hints guys.
Comment 18 Matias Laporte 2022-03-20 22:23:55 UTC
fyi I use Kubuntu with TLP and still had this problem (I am not sure if I have it anymore, as I stopped using headphones from the dock), so I doubt that was the problem in my case.
Comment 19 James Liu 2022-11-21 22:50:38 UTC
I'm experiencing the same issue on Fedora 36 with kernel 6.0.8-200.fc36.x86_64.

I have an Audioengine A2+ (which has a built-in DAC) connected over USB to a Caldigit TS4 Thunderbolt dock, which is in turn connected to my machine via a Thunderbolt 4 cable.

The issue presented itself after either:

- upgrading to kernel 6.x
- attaching an LG 28MQ780-B display to the Caldigit TS4 dock via USB-C.

I don't remember what specifically changed about my setup as I reconfigured my peripherals after upgrading my display. I hadn't previously experienced this issue with a different monitor on the same Fedora installation.

Running `stress -c 1` also fixes the crackling for me, at the expense of wasted CPU cycles.
Comment 20 Foobar 2022-11-24 21:21:19 UTC
Same issue with 5.15.78-1-MANJARO
Also over a thunderbolt 3 dock, also goes away with CPU load.

Do not have TLP, only auto-cpufreq which only sets the governor in my case performance.
Tried turning off turbo boost, no difference.

Here are 2 more related posts i found:
https://bbs.archlinux.org/viewtopic.php?id=265932
https://bbs.archlinux.org/viewtopic.php?id=264974
Comment 21 z411 2022-11-29 08:05:27 UTC
I've also got this problem, but it presents only after a few hours of usage.

As James said, I think it started happening after I updated to kernel 6.x
I have a Topping D10 USB compliant audio interface.

Tried over Pipewire and plain ALSA (no sound server), same result. I'll try stress next time to see if it's related.
Comment 22 z411 2022-12-01 22:06:27 UTC
I got the bug again and I can confirm it gets solved when I run stress -c 12, but returns if I stop it. For some reason it starts happening after several hours of uptime.

I don't see why it happens, other than updating to kernel 6.x, and I think it happens after I plug my smartphone to an USB port. dmesg shows the phone is a high speed device using xhci_hcd - probably a bug here?