Problem description

I am trying to get the audio to work correctly in my Linux installation. However, every time the audio signal goes to zero, even for only about half a second, and when it comes back up, I hear a click/pop from my speakers. This is most obvious when listening to sources without constant background noise, wherein the clicks happen each time a character begins or stops talking and any time one pauses or restarts music playback. While typical modern movies are never completely silent, certain type of content, such as talk shows or push-to-talk voice communication software, are completely ruined.

System hardware and software setup

I have built a media PC with an Intel i5 processor. The motherboard is an ASUS Prime B560M-A and the display being used is an LG CX series OLED. I am using Debian testing (Bullseye) and Pulseaudio, which comes default with Debian.

Sound is sent outwards through HDMI1 and the TV forwards it to a Harman Kadron AVR (171S) through its audio return channel (ARC). Pulseaudio output mode is "HDMI1 Digital Stereo" with several pass-through audio formats enabled.

Problem isolation and presumed cause

It seems that audio system power saving (or other) functions in Debian shut down the audio signal immediately when it detects complete silence. This causes the AVR to turn off its audio output, which produces the click. The same happens in reverse, when sound resumes.

I can confirm this by observing the audio format indicator in my AVR. When I switch to a source from my amplifier, it displays the format being received. If there is a signal, the AVR displays "2/0/0 48kHz ARC" (for regular PCM) or something like 3/2/1 48kHz ARC (for DTS). In Debian, when I switch to the ARC input at any time when audio volume is at zero, the receiver displays "--- ARC", which indicates no signal at all. It really seems like the signal is immediately killed when it reaches zero.

How do I know that this is a Linux/Debian issue

At this point there are still multiple options. It could be that the AVR itself is shutting down if it is only receiving zeroes, and it could also be that the TV stops sending any signal if it is only receiving zeroes. However, the TV is in the simplest possible pass-through mode, and I can isolate the problem to Debian by testing the same setup through a Playstation 4 console.

In the exact same situation, when absolutely no sound is being played by the PS4, the AVR still reports "2/0/0 ARC". When the audio playback stops or continues, there are no cracks and pops whatsoever. I.e. with the PS4, the audio signal never cuts out completely.

What have I tried?

I have searched for this site and the internet at large for people with similar problems, and found the following advice.

This has been set to 0:


This has been set to N:


These changes have been made permanent:

root@mycomputername|/etc/modprobe.d:cat audio_disable_powersave.conf
options snd-hda-intel power_save=0 power_save_controller=N

I have turned off muting idle sinks in pulseaudio at locations


by commenting out the line:

### Automatically suspend sinks/sources that become idle for too long
#load-module module-suspend-on-idle

Pulseaudio has been restarted after this change.

I have also enabled silent stream in the hdmi output module by setting this to Y:


It was made permanent the same way as the module settings above.

Additionally, I have disabled the "Auto Mute Mode" from Alsamixer, though this should not have any effect as I believe it is related to the headphone jack.

Several sources also suggest sending a stream of zeroes through aplay to keep the signal alive. I have done this by using:

aplay /dev/zero -f S16_LE

None of the above have had any kind of effect. Pressing pause always produces an immediate click, and any silence in the output always produces an immediate click. Checking the AVR signal mode after this always shows, that it is not receiving any signal at all.

I'm absolutely at my wits end and can't think of anything else to try, and would very much appreciate help from anyone who has actually solved this issue.

  • 1
    To debug this, you need to "divide and conquer" and try to narrow down where in all the audio components that happens. First step is to take Pulseaudio out of the picture. So stop Pulseaudio (or use pasuspender), and use aplay -D ... with the right destination (aplay -L, use plughw:... with the one for HDMI1) with a WAV file with silences. Observe if the clicks happen on the silences, or on repeated aplay. Also try hw:..., but then you need a WAV file with the right sample rate.
    – dirkt
    Commented Aug 5, 2021 at 10:05
  • I ended up testing these. Tried multiple digital outputs with and without pulseaudio. No solution seems to exist. Whatever I do, the output shuts down after around 0.5sec of complete silence. Either this behavior is somewhere really deep in the drivers I use, or the AVR requires a keep-alive signal of some sort, which the PS4 can provide but Linux cannot.
    – Warma
    Commented Aug 5, 2021 at 20:45
  • 1
    "0.5 of silence" sounds like it's something in the AVR. So, time to experiment some more: Use e.g. sox to produce some low volume sinus of different frequencies, and see if it shuts down again. Also try a constant non-zero signal (which shouldn't be audible). Not sure if sox can do that, you may have to make a WAV file. If you can find some non-audible non-zero signal that prevents shutting down, then you can constantly play this.
    – dirkt
    Commented Aug 6, 2021 at 5:56

1 Answer 1


In the end, I did not find a satisfactory answer, and there seems to be no good solution for my case, possibly because of the automation in the AVR. It is still unclear why the PS4 is capable of keeping the signal alive, but at least the following does the same:

/usr/bin/play -qn synth sin 10 gain -191

It is below both the sensitivity of my speaker and its lower frequency cutoff. If this is active, I can pause music without hearing a pop.

(edit): No-one has provided a better solution, and as a consequence, I am accepting this answer. Furthermore, to make the answer more generally useful, it is worth noting that if your signal output data format is 16-bit instead of 32-bit, use:

/usr/bin/play -qn synth sin 10 gain -95

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .