Bug 202455 - Crackling audio over USB-C monitor
Summary: Crackling audio over USB-C monitor
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Sound(ALSA) (show other bugs)
Hardware: Intel Linux
: P1 normal
Assignee: Jaroslav Kysela
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-01-30 01:36 UTC by David Bazile
Modified: 2022-01-15 18:41 UTC (History)
9 users (show)

See Also:
Kernel Version: 4.20.3
Tree: Mainline
Regression: No


Attachments
alsa-info-output (after several attempts to troubleshoot).txt (27.93 KB, text/plain)
2019-01-30 01:36 UTC, David Bazile
Details
alsa-info.sh output (after reboot) (41.09 KB, text/plain)
2019-01-30 01:45 UTC, David Bazile
Details
Output of alsa-info.sh (80.82 KB, text/plain)
2019-03-13 18:12 UTC, C Snell
Details
alsa-info output (40.00 KB, application/x-tar)
2019-04-16 23:31 UTC, Noah Worky
Details
lspci -v output (8.41 KB, text/plain)
2019-04-16 23:34 UTC, Noah Worky
Details
dmesg output after boot (75.57 KB, text/plain)
2019-04-16 23:34 UTC, Noah Worky
Details

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

Note You need to log in before you can comment on or make changes to this bug.