I output audio through HDMI to my receiver, via an AMD gpu (a 9070xt), via pipewire. Since upgrading kernels past 7.0.0-27, there are crackling noises and xruns during lots of different kinds of playback, and even when idle. The receiver makes a small popping noise when the audio stream is interrupted, which happens multiple times per second often times even when no audio is playing.
Increasing pipewire’s quantum to very high numbers (like 64k, over half a second) does not seem to fix this. It also happens when the system is idle, not just under load; the only fix I’ve found is to keep booting with the 7.0.0-27 kernel. Playing completely silent audio from certain programs like audacity seems to help, but is not really a fix.
I vaguely suspect this might be an issue with amdgpu but I really can’t tell and don’t know how best to debug it from here.
Since 7.0.0-27 is the last kernel without the crackling, run apt changelog linux-modules-$(uname -r) on the current kernel and look for amdgpu, drm, and HDA audio entries added after 7.0.0-27. Then run journalctl -k -f while the receiver pops and check whether amdgpu or snd_hda_intel logs a line at each pop. Also run pw-top at idle and watch the ERR column for the HDMI sink. Report it with ubuntu-bug linux while booted into the crackling kernel so the bug carries that kernel’s version and logs.
There are a zillion entries in those categories in the changelog since 7.0.0-27, and there are no log lines in the journal or dmesg about it. Nor is there anything going on in the ERR column.
The pops don’t stop when disabling snd_hda_intel/power_save, and the pops when idle (and skips when playing audio in firefox) remain as aggressive as always: irregularly, multiple times per second.
I already have wireplumber set up with session.suspend-timeout-seconds = 0 for a few years now to avoid sinks going into suspend for basically the same reason. The active outputs never go into suspend and are locked to 96khz sample rate, visible in pw-top.
Right, if wireplumber already keeps it awake at 96 kHz, scratch that then.
Could it be DCN memory downclocking instead?
At 96 kHz, if the DCN latency watermark is too tight, the audio FIFO could underrun whenever the GPU drops MCLK at idle, making the receiver lose sync.
Try locking the GPU clocks to test that:
echo "high" | sudo tee /sys/class/drm/card0/device/power_dpm_force_performance_level
If the pops stop, that points straight to an amdgpu DCN watermark regression.
It isn’t HDA power saving or GPU clock changes, then. With no journal lines and no pw-top errors at each pop, the drop is most likely in the HDA or amdgpu driver below PipeWire. Does the popping stop on 7.0.0-34 if you remove snd-hda-intel.snoop=0 from the kernel command line for one boot?
I’ve also tested lowering the sample rate to 48khz (from pipewire config, from a fresh boot) and the skipping is still really bad. (Possibly even worse, like the gaps in the playback are longer, but I’m not totally confident.)
It would be disingenuous to reply using text generated by AI without disclosure. I review everything myself and validate the troubleshooting, but the words are often not my own.
I would try the latest upstream kernel from the Ubuntu Mainline page, just as a test (well, the builds seems to be broken again, so kernel 7.3-rc3 is the most recent posted). The purpose of the test is to know if the issue has already been fixed upstream, and it just hasn’t worked its way downstream yet. Otherwise I only know to bisect the kernel (a considerable amount of work, and typically about 15 kernel compiles) to isolate the specific commit that caused the issue.