4

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.

| improve this question | |
  • First step is to pinpoint what's causing it. Assuming you are running Pulseaudio, use paplay to play a wav file. If the effect persists, stop Pulseaudio and use aplay with a wav file. After that, you should know if it's ALSA, Pulseaudio, or a layer above. – dirkt Apr 30 '17 at 7:44
  • @dirkt updated the question. – pepper_chico Apr 30 '17 at 7:57
  • Just to make sure: You stopped Pulseaudio before using aplay, and verified with ps axu? I.e., pasuspender, or pulseaudio --kill, or whatever Arch Linux needs? If you didn't, aplay will still use Pulseaudio through the compatbility layer. Any messages in dmesg or syslog? If you can't hear the first part at all, maybe the initial data is dropped for some reason. If you do hear it at lower volume, I have currently no explanation. – dirkt Apr 30 '17 at 9:42
  • @dirkt to really make sure I've stopped pulseaudio and it didn't restart I've renamed the binary to /usr/bin/pulseaudio.bak and then stopped the current running instance. There's no pulseaudio in the process list. After this aplay doesn't play any sound: it's muted. – pepper_chico Apr 30 '17 at 17:02
  • @dirkt not sure if relevant, I'm using Gnome 3. – pepper_chico Apr 30 '17 at 17:03
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).

| improve this answer | |
  • Thanks for this tip but I have excluded this solution in the question itself. – pepper_chico May 1 '17 at 6:22
  • As expected... this fix the problem... I just can't believe I'll have to put this in the background to circumvent it, this feels so hacky. – pepper_chico May 1 '17 at 6:30
  • For now I'll be using play -qn on autostart ¯_(ツ)_/¯ – pepper_chico May 1 '17 at 6:44
  • I'm guessing soundcard and codec is not being recognized now because I'm on a Z270 motherboard with SupremeFX S1220 Audio CODEC (ALC1220 I guess). Support is on 4.11 which should arrive on ArchLinux in the coming hours/days. – pepper_chico May 2 '17 at 1:21
  • 1
    Updated the question with new information. I guess only thing left is a bug report to ALSA development. – pepper_chico May 23 '17 at 17:49
0

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

| improve this answer | |

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.