Via SPDIF hearable sound starts late, e. g. in the Test Sound dialog I maximally can hear "Left" when the voice should say "Front Left".

When I have pavucontrol open (in the background) whilst clicking on the Test Sound it starts immediately.

Generally, starting any audio/media file, the beginning is not output/hearable. Connecting either optical or coaxial. This only seems to affect Ubuntu 12.10, wasn't the case in 12.04, doesn't seem to be the case in 13.04!

From ubuntuusers.de a bit of help -- playing a non hearable sinus to keep spdif alive:

apt-get install sox
play -n -c2 synth sin gain -100   # -c2 for two channels

Hardware on an ASRock 970 Extreme3 (and GeForce 210):

$ cat /proc/asound/cards
 0 [SB             ]: HDA-Intel - HDA ATI SB
                      HDA ATI SB at 0xfe200000 irq 16
 1 [NVidia         ]: HDA-Intel - HDA NVidia
                      HDA NVidia at 0xfe080000 irq 25

$ cat /proc/asound/card0/codec* | grep Codec
Codec: Realtek ALC892

Some pulseaudio -v output pasted to http://paste.ubuntu.com/5629082/

Can I upgrade from pulseaudio 2.1 somehow?

Live Ubuntu 13.04 output pasted to http://paste.ubuntu.com/5630475/ -- actually here only the very first invocation of sound (or after some long user pause?) starts delayed, ie after "... Left", "Front Right" is heard whereas in 12.10 it's always "... Left", " ... Right".

  • 1
    Can you give more information about the sound card and on what it is connected? Can you try with jackd if this the case too ? because it may be related to Pulse Audio and not to the sound card.
    – ttoine
    Mar 19, 2013 at 11:22
  • Realtek ALC892 seems to offer lots of hits in google to mine thru :/
    – type
    Mar 19, 2013 at 22:31
  • installing the driver from the manufacturer as in community.linuxmint.com/tutorial/view/1236 didn't help either. one line reads: { .id = 0x10ec0892, .name = "ALC892", .patch = patch_alc662 },
    – type
    Mar 19, 2013 at 23:17

8 Answers 8


I know I'm about to revive an old thread, but I have found a easy working solution that fixes the problem.

From : https://wiki.archlinux.org/index.php/PulseAudio

To disable loading of the module-suspend-on-idle module, comment out the following line in the configuration file in use (~/.config/pulse/default.pa or /etc/pulse/default.pa):

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

Finally restart PulseAudio to apply the changes.

  • 1
    This was the answer for me too, but it has a downside. I have some audio programs use ALSA to directly pass a particular format to a home theatre receiver for decoding rather than use PA’s sometimes dodgy resampling. This works easily because of this very same suspend function. Mar 12, 2017 at 8:19
  • 8
    This saved my day!! Why the hell does this comes as a default setting? This is the kind of thing that makes a user think "Oh linux is not good, audio is laggy"
    – Daniel
    Nov 6, 2020 at 22:36
  • How do you restart PulseAudio? I had to reboot the OS, because after --kill, --start the OS could not connect to the service anymore
    – DarkTrick
    Sep 19, 2021 at 4:00
  1. Find PulseAudio config files which contains load-module module-suspend-on-idle lines:

    neatsoft@desktop:~$ grep module-suspend-on-idle /etc/pulse/*
    /etc/pulse/default.pa:load-module module-suspend-on-idle
    /etc/pulse/system.pa:load-module module-suspend-on-idle
  2. Comment out that lines.

  3. Restart PulseAudio to apply the changes:

    pulseaudio -k

Just tested on Ubuntu 17.04 and it works fine.

  • 1
    This worked for me in 19.04, except for the restart part. I had to reboot to restart pulseaudio because pulseaudio -k gave me some errors.
    – muclux
    Apr 21, 2019 at 9:02

It sounds like power management is preventing the soundcard from outputting the first snippet of audio. From http://wiki.gentoo.org/wiki/Power_management/Soundcard, the important bits are as follows:

Runtime tuning

You can tune the driver in the sysfs filesystem under /sys/module/snd_hda_intel/parameters

The power_save_controller knob controls, if power-saving mode is enabled. It's preset by the kernel option ... power-saving ....

The power_save knob sets the time-out in seconds. It's preset by the kernel option Default time-out ...


pm-utils contains a script to enable the power-saving mode when on battery and disable when on AC. It overrides the default values of the kernel.

If you use pm-utils, but don't want this kind of regulation, disable the script: root # touch /etc/pm/power.d/intel-audio-powersave

From the above text, the things to try are:

  1. in the terminal, run the following and try playing audio again:

    echo N | sudo tee /sys/module/snd_hda_intel/parameters/power_save_controller

    If audio is fine, then you need to make it permanent by adding a new file in /etc/modprobe.d/ with the following content:

    options snd_hda_intel power-saving=N
  2. run sudo touch /etc/pm/power.d/intel-audio-powersave and reboot

    if the fix worked then audio should play normally, if not then remove the file again:

    sudo rm /etc/pm/power.d/intel-audio-powersave

If neither of these work, then I'm out of ideas :-).

  • Awesome answer, thanks a lot! Unfortunately no change yet.
    – type
    Mar 19, 2013 at 22:30
  • what type of "new file" am I supposed to make in etc/modprobe.d/ ? May 2, 2016 at 13:29

The accepted answer about not loading module-suspend-on-idle doesn't fix the issue for me. To "fix" this I had to leave a continuous silence command running in the background, see UPDATE 2 of the following question:

And I've reproduced this problem both in laptop's internal speakers and PCs through HDMI and headphones, no need for SPDIF, on latest ArchLinux and Ubuntu.


This is a general issue with SPDIF/digital out and the receiver processing the signal, etc. If there is no signal, the receiver go into an idle mode. It takes from a few to a few hundred milliseconds to begin to play the signal. The ONLY way to fix it is to cause your SPDIF output to constantly send SOME signal, thus keeping the receiver processing alive at all times. At the moment, I just solved this problem in Windows using a tiny utility some guy wrote in .NET that outputs a null signal at all times. He calls it SPDIF Keep-Alive. This keeps the signal flowing and my receiver constantly listening. I have not yet seen a way to do this for Linux, but I would imagine the support to create such a thing is EVERYWHERE. Hopefully, this has given someone an idea on what to search for or where to look next! -K9SPY

Digital audio keep-alive keep alive SPDIF Keep-Alive keep alive TOSLINK keep-alive keep alive times out goes to sleep powers down SPDIF sound delay


I need to run a special "inaudible" sound file (silence does not work for me) on Ubuntu 18.04 and Xubuntu 20.04 - but same back to Debian 6!

What worked for me: How to Fix First Play of Sound Delayed, Missed or Muffled


For me this worked:

  • In /etc/pulse/daemon.conf:
    • set default-sample-rate to 48000
    • set alternate-sample-rate to 48000

Source: This Gitlab issue:


I have run into this problem with audio over HDMI, while audio over USB was working perfectly fine at the same time. In fact, even audio over HDMI is only buggy for me with one specific monitor, so I assume that it is this monitor that turns off its sound system in the absence of a sound signal and requires some time for starting it.

The removal of module-suspend-on-idle did not fix HDMI audio for me and instead of the other suggestion of playing a silent audio file in a loop, I came up with a slighly nicer way of keeping the connection alive by connecting a null source to the sound output. The way I did it is by first loading the null source and loopback modules using the following commands:

pactl load-module module-null-source
pactl load-module module-loopback

This should usually suffice as by default the loopback will connect the null source to the default sound output. However, if you have used these modules earlier and connected them in some other way, then those connections will be remembered and reapplied. In this case one can wire them up correctly in an interactive manner in pavucontrol:

  1. On the Recording tab, connect the input of the loopback device to the null input.
  2. On the Playback tab, connect the output of the loopback device to the HDMI output.

(If the loopback device is missing from the device list, "Show: All streams" must be selected on the bottom first.)

It must be possible to do the second part with command line parameters as well, but since pulseaudio remembers the module connections anyway, I never needed to connect the devices again since my intial experiment. Once the devices are correctly connected once, in the future it is sufficient to load the two modules either using the commands from above or by adding

load-module module-null-source
load-module module-loopback

to the config file (~/.config/pulse/default.pa or /etc/pulse/default.pa).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.