HDMI audio dropouts with AMD – fixed

Ask Fedora
,
1

Hi everyone,

I’m new to Fedora and this is my first post - translated with AI.

I recently switched from Windows and really enjoy using Fedora so far — but I ran into a confusing audio issue and wanted to understand what’s happening under the hood.
Please excuse me if I miss some Fedora customs, I’m still learning.

The Issue for my audio setup:
Using an AMD RX 6600 (Navi 23) GPU via HDMI to a Pioneer AV receiver, I noticed two problems:

  1. After pausing a video for ~10 seconds, the first 1–2 seconds of sound were missing when playback resumed.
  2. Occasionally, there were short random audio dropouts during playback, especially in Firefox and on YouTube (or other similar streaming sites).

On Windows, the exact same setup works without any gaps or delay.

It seems Fedora’s audio stack behaves differently:

  1. PipeWire and the AMD HDMI driver both stop sending audio frames during silence to save power?
  2. When playback resumes, the HDMI clock has to re-synchronize, which takes about two seconds.
  3. Additionally, the default PipeWire buffer size (quantum = 512–1024) is a bit too small for HDMI on this GPU, which can cause tiny underruns → audible dropouts.

So I went creative and solved the problems a bit shady, maybe there are better solutions:

Keep HDMI active with a silent audio stream

I created a long, silent WAV file and let VLC play it in the background on loop.
That keeps the HDMI audio clock alive — no delay when pausing or resuming videos:

  • ffmpeg -f lavfi -i anullsrc=r=48000:cl=6 -t 10:00:00 -q:a 9 ~/.local/share/sounds/hdmi-silence.wav
    cvlc --intf dummy --no-video --quiet --loop ~/.local/share/sounds/hdmi-silence.wav &

Increase PipeWire buffer size to stop small dropouts

Then I added this configuration:
~/.config/pipewire/client.conf.d/10-buffer.conf
context.properties = {
default.clock.rate = 48000
default.clock.allowed-rates = [ 44100 48000 ]
default.clock.quantum = 2048
default.clock.min-quantum = 1024
default.clock.max-quantum = 4096
}

After restarting PipeWire, HDMI audio became perfectly stable —
no more missing seconds after pause, no random glitches.

Is there a reason why Fedora / PipeWire don’t use a slightly larger buffer or a built-in keepalive stream for HDMI audio by default? It would make things feel much more seamless, similar to how Windows handles it.

Thanks a lot for reading, and sorry if this is a common topic — I’m still getting used to Fedora’s audio configuration and would love to understand the reasoning behind these defaults.

Best regards,
a new fedora user

1 Like
2

Welcome to Fedora!
For a new user you got some ninja skills!
Hope you stick around and you could help out in Ask Fedora, if you want even more Fedora action, jump on our Matrix chat and introduce yourself and find a working group to get involved with :smiley:

3

It’s a known problem. Rather than continuously transmitting a silent audio stream, you can change the power save settings in WirePlumber as documented here: PipeWire - ArchWiki

1 Like
4

Thanks for your reply! But I tried that already (both system-wide and in ~/.config/wireplumber/…)
It prevents PipeWire from suspending the node, but the AMD HDMI audio hardware still powers down when no data is sent.
On the RX 6600 this means the HDMI clock stops after a few seconds of silence, so the AVR needs to re-lock – causing the 1–2 s delay.
So the WirePlumber setting may helps partially, but doesn’t stop the GPU itself from suspending.

1 Like
5

Ah, I see. There are separate settings to control the power management for the whole AMD card. Maybe options amdgpu runpm=0 saved in a conf file under /etc/modprobe.d would work. I’m not sure. (Use modinfo -p amdgpu to view all the driver settings.)

6

I just tried that, but unfortunately it doesn’t change anything.
Even with amdgpu.runpm=0, the HDMI audio part of the GPU still powers down after a few seconds of silence. So the short delay on resume is still there - only the continuous silent-audio workaround keeps the HDMI link fully active for me :s

1 Like
7

FWIW, there is also a power management setting for the PCIe bus that the AMD card is connected to.

Unfortunately, power management under Linux is quite complex.

8

Not just under Linux, but greater involvement of hardware vendors in Windows hides some of the complexity from users. Linux is often used on older systems that are no longer suitable for current Windows versions. Linux power management has been evolving. Settings that worked last year may not work now, and vendor firmware updates may be required.

1 Like