Short audio playback is muted, requires warming up or secondary audio in background

Question

I have noticed this happens both in my ArchLinux PC as well as in my ArchLinux MacBook. I need to get application notifications through short audio tones and I've figured out that it's not an issue due to notifying applications but the system itself, and it happens in both systems which are widely different.

When I play a short audio file, like paplay /usr/share/sounds/freedesktop/stereo/message.oga I don't hear it the first time I play it.

If I play it again in sequence, I hear it and it's played correctly, at all times I repeat it in sequence.

If I wait around 10 seconds to play it again, it's muted (like in the beginning): it sounds only when warming up.

The same happens for aplay /usr/share/sounds/alsa/Front_Left.wav, but as it's a longer tone, the issue happens just on the start of the file. At first I only hear "t left", missing "fron". Afterwards I hear it in full and clear: "front left". If I wait 10 seconds, "t left" again.

The issue doesn't happen if I'm playing a music file in the background in a media player. It happens only when the computer is not playing any sound.

How to fix this? (except for keeping the PC playing an inaudible sound in daemon in the background to keep it warmed up always)

Relevant test session where the problem persists solely using alsa:

~ ❯❯❯ sudo mv /usr/bin/pulseaudio /usr/bin/pulseaudio.bak
~ ❯❯❯ pulseaudio.bak --kill
W: [pulseaudio.bak] main.c: Couldn't canonicalize binary path, cannot self execute.
~ ❯❯❯ paplay /usr/share/sounds/freedesktop/stereo/message.oga
Connection failure: Connection refused
pa_context_connect() failed: Connection refused
~ ❯❯❯ ps axu | grep -i pulse
francis+ 31563  0.0  0.0  10796  2144 pts/2    S+   14:35   0:00 grep --color=auto -i pulse

~ ❯❯❯ aplay -D plughw:0,7 /usr/share/sounds/alsa/Front_Left.wav
Playing WAVE '/usr/share/sounds/alsa/Front_Left.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono

~ ❯❯❯ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: PCH [HDA Intel PCH], device 0: Generic Analog [Generic Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 1: Generic Digital [Generic Digital]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 7: HDMI 1 [HDMI 1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
~ ❯❯❯ lspci -nn | grep -i audio
00:1f.3 Audio device [0403]: Intel Corporation Device [8086:a2f0]

UPDATE

After Linux kernel 4.11.2, ALC1220 codec is in:

~ ❯❯❯ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: PCH [HDA Intel PCH], device 0: ALC1220 Analog [ALC1220 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 1: ALC1220 Digital [ALC1220 Digital]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 7: HDMI 1 [HDMI 1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 8: HDMI 2 [HDMI 2]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 9: HDMI 3 [HDMI 3]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

I've connected my headphones and managed to reproduce the issue just using aplay but differently:

~ ❯❯❯ aplay -D plughw:0,0 /usr/share/sounds/alsa/Front_Left.wav
~ ❯❯❯ aplay -D plughw:0,0 /usr/share/sounds/purple/alert.wav
~ ❯❯❯ aplay -D plughw:0,0 /usr/share/sounds/alsa/Front_Left.wav
~ ❯❯❯ aplay -D plughw:0,0 /usr/share/sounds/purple/alert.wav
...

I had to play different audio files residing in different directories, both playbacks are cut at the start if one is played and then the other, interval between playbacks doesn't matter. If a file is played once, playing files in the same directory afterwards will not reproduce the issue, nor waiting for it to "cool down" (I've wait 1 minute). Same happens with paplay when turning on pulseaudio. When playing through HDMI, it reproduces in both test cases.

UPDATE 2

Lazy as I am, I didn't report this to ALSA developers, yet, but, I've create a user systemd unit:

[Unit]
Description=Continuous silence

[Service]
ExecStart=/usr/bin/play -qn

[Install]
WantedBy=default.target

Just save it to ~/.config/systemd/user/continuous-silence.service and enable it with systemctl --user enable continuous-silence.

Answer 1

Under the assumption that the receiving sound system needs to "wake up" before it output sounds, and it only does so after receiving the initial batch of sound data, dropping the first batch, if this can't be fixed in the receiving sound system, a workaround is to continously output silence, for example with play from sox:

play -n

Edit

With the additional information that it works on Windows, and the information that neither the soundcard ("Intel Corporation Device") nor the Codec ("Generic") is recognized by name, it's also possible that is is some driver issue. There's a "keep alive enable" (KAE) bit in the Codec, maybe this needs to be set, possibly by a mixer control, but I don't know enough about this.

File a bug with the ALSA developers, provide the lspci -nn information, and the output of cat /proc/asound/card*/codec\#*. (You can also put the output of the latter into a pastebin and edit your question with the link, so I can have a look).

Answer 2

Another fix for me happened when I started adopting Jack Audio Connection Kit coupled with pulseaudio-jack, instead of bare pulseaudio.

Answer 3

Fixed by following the wiki on howto setup low-latency audio

• Follow Section 1.1 on the wiki https://wiki.archlinux.org/title/Professional_audio
• Do Not Install linux-rt AUR kernel
• Rebooting after completing Section 1.1 should eliminate the latency
• If not then proceed with the rest of the wiki and configuring JACK