A reprodução curta de áudio é silenciada, requer aquecimento ou áudio secundário em segundo plano

Question

Eu notei que isso acontece tanto no meu PC ArchLinux quanto no meu ArchLinux MacBook. Eu preciso obter notificações de aplicativos por meio de tons de áudio curtos e descobri que não é um problema devido à notificação de aplicativos, mas ao próprio sistema, e isso acontece em ambos os sistemas, que são muito diferentes.

Quando reproduz um arquivo de áudio curto, como paplay /usr/share/sounds/freedesktop/stereo/message.oga , não ouço na primeira vez que o reproduzo.

Se eu reproduzi-lo novamente em sequência, eu ouço e é tocado corretamente, em todos os momentos eu repito em sequência.

Se eu esperar cerca de 10 segundos para reproduzi-lo novamente, ele será silenciado (como no começo): soará apenas quando estiver aquecendo.

O mesmo acontece com aplay /usr/share/sounds/alsa/Front_Left.wav , mas como é um tom mais longo, o problema acontece apenas no início do arquivo. No começo eu só ouço "t left", faltando "fron". Depois eu o ouço de forma clara e completa: "frente esquerda". Se eu esperar 10 segundos, "t left" de novo.

O problema não acontece se eu estiver reproduzindo um arquivo de música em segundo plano em um media player. Isso acontece somente quando o computador não está reproduzindo nenhum som.

Como consertar isso? (exceto por manter o PC tocando um som inaudível no daemon em segundo plano para mantê-lo aquecido sempre)

Sessão de teste relevante em que o problema persiste unicamente usando o 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

Após o kernel do Linux 4.11.2, O codec ALC1220 está em :

~ ❯❯❯ 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

Conectei meus fones de ouvido e consegui reproduzir o problema usando apenas aplay , mas de forma diferente:

~ ❯❯❯ 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
...

Eu tive que reproduzir diferentes arquivos de áudio residentes em diretórios diferentes, ambas as reproduções são cortadas no início, se uma for tocada e, em seguida, a outra, intervalo entre as reproduções não importa. Se um arquivo for reproduzido uma vez, reproduzir arquivos no mesmo diretório depois não reproduzirá o problema, nem esperará que ele "esfrie" (espere 1 minuto). O mesmo acontece com paplay ao ativar o pulseaudio. Ao jogar através de HDMI, reproduz em ambos os casos de teste.

ATUALIZAÇÃO 2

Preguiça como eu sou, eu não relatei isso para desenvolvedores da ALSA, mas, mas, eu criei um unidade de sistema do usuário :

[Unit]
Description=Continuous silence

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

[Install]
WantedBy=default.target

Basta salvá-lo em ~/.config/systemd/user/continuous-silence.service e ativá-lo com systemctl --user enable continuous-silence .

    

Answer 1

Supondo que o sistema de som receptor precisa "acordar" antes de emitir sons, e só o faz após receber o lote inicial de dados de som, soltando o primeiro lote, se não pode ser corrigido no sistema de som de recepção, uma solução alternativa é continuamente saída de silêncio, por exemplo, com play de sox :

play -n

Editar

Com as informações adicionais que ele funciona no Windows e as informações de que nem a placa de som ("Dispositivo da Intel Corporation") nem o Codec ("Genérico") são reconhecidos pelo nome, também é possível algum problema de driver. Há um bit "keep alive enable" (KAE) no Codec, talvez isso precise ser configurado, possivelmente por um controle de mixer, mas eu não sei o suficiente sobre isso.

Arquive um bug com os desenvolvedores da ALSA, forneça as informações de lspci -nn e a saída de cat /proc/asound/card*/codec\#* . (Você também pode colocar a saída deste último em um pastebin e editar sua pergunta com o link, para que eu possa dar uma olhada).