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 280865 [details]
alsa-info.sh output (after reboot)
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. Created attachment 281813 [details]
Output of alsa-info.sh
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. Created attachment 282353 [details]
alsa-info output
Created attachment 282355 [details]
lspci -v output
Created attachment 282357 [details]
dmesg output after boot
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). 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. 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. 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. 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. 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 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 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 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 ``` 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. 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. 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. 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 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. 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? |