Estou tendo um problema semelhante com o Pulseaudio 6.0. O Pulseaudio tende a não tocar ou travar após alguns minutos de reprodução. Também usando Arch Linux. Tentei tanto o modo de usuário (executando como root) quanto o modo de sistema, já que tenho o Pi configurado sem cabeça.

A seguir está o erro impresso por Pulseaudio sempre que travar (após cerca de um ou dois minutos de reprodução, normalmente)

E: [alsa-sink-bcm2835 ALSA] alsa-sink.c: ALSA nos acordou para gravar novos dados no dispositivo, mas na verdade não havia nada para escrever!
E: [alsa-sink-bcm2835 ALSA] alsa-sink.c: Provavelmente este é um bug no driver ALSA '(nulo)'. Relate esse problema para os desenvolvedores do ALSA.
E: [alsa-sink-bcm2835 ALSA] alsa-sink.c: Fomos acordados com POLLOUT definido - no entanto, um snd_pcm_avail () subsequente retornou 0 ou outro valor <min_avail.

Eu também estou tendo problemas terríveis com o bcm2835 e o pulso 6.
Se eu iniciar o pulseaudio e executar o paplay localmente (no pi), ele começa a tocar imediatamente com o áudio todo truncado. Partes do PCM parecem estar sendo reproduzidas fora de ordem. Quanto mais tempo o áudio é reproduzido, pior fica até que o áudio seja quase puro ruído.
Matar (CTRL + C) e executar a pausa subsequente causa um padrão repetível de distorção do áudio ou puro silêncio, até que na 8ª execução o áudio seja reproduzido perfeitamente. Jogue novamente e o ciclo é reiniciado.
O padrão é truncado, silencioso, truncado, truncado, silencioso, truncado, silencioso, perfeito.
Se eu usar um fone de ouvido USB, o paplay funciona sempre.
Eu o tive onde tenho o áudio reproduzido no fone de ouvido USB perfeito e, em seguida, desconecto o dongle USB e o áudio é reproduzido corretamente na porta analógica do pi. Pare e reinicie o áudio e ele ficará truncado.

Minha configuração: pulseaudio + mpd + ncmpcpp.

Minha configuração de teste é iniciar uma música e reproduzir / pausar repetidamente. Após no máximo 3 vezes de reprodução / pausa, o pulso de áudio irá travar e deverá ser reiniciado.
Isso só acontece no meu Raspberry B + com o chip bcm2835, tanto com distribuições baseadas em Debian quanto em Arch. Não tenho problemas com exatamente a mesma configuração em meu PC de mesa com um chip de som Intel. O problema não existia com o kernel 3.6 (mas não quero usar uma distribuição antiga).

Nenhuma das soluções alternativas encontradas na web (tsched = 0, desabilitar o módulo-suspend-on-idle, ...) funcionou. Finalmente desistirei desse problema porque não encontrei uma solução por mais de um ano. Ou comprarei um Raspberry 2 ou usarei mpd com o back-end ALSA, porque funciona muito bem.

@maxnet este problema foi resolvido? Se sim, feche este problema.

Acho que não. Ele também não funciona com o Raspberry 3 (o que não é de se admirar, porque usa o mesmo chip / driver: snd_bcm2835).

Eu tenho esse problema no meu Raspberry 3 executando o Ubuntu 16.04. Para contornar o problema, colocarei um atraso de tempo limite de 5 segundos no meu programa, mas isso atrapalha a naturalidade da saída (é um sintetizador de voz)

O mesmo problema com meu pi3 e ubuntu mate 16.04 e mpd parece fantástico, a menos que eu altere o volume (o que causa gagueira ou perda de som) também perde o som aleatoriamente entre outros problemas. Realmente frustrante.

Mesmo problema em Rpi B (não 2 ou 3) com o kernel mais recente (684be4bc8cc343f60fdc3240c6d55d41d0a5b56c)

Pode confirmar esse problema com um rpi3 executando Linux raspberrypi 4.9.27-v7+ #997 SMP Tue May 9 19:58:37 BST 2017 armv7l GNU/Linux no raspbian .. Pulseaudio geralmente para de tocar entre as faixas que eu alimentei a partir do mpd (de outro host via rede). Ao tentar reproduzir áudio flac de 24 bits via mpd para pulsar, ele reproduz apenas 2 segundos e congela.

Confirmando problema no rpi3 executando 4.9.30-v7+ . Preencher a lista de reprodução de mpds e iniciar a reprodução geralmente funcionará até que a lista de reprodução seja concluída, mas alterar manualmente as faixas, parando e reiniciando, fará com que a saída de áudio pare de funcionar, até que eu reinicie o mpd.

audio_output {
        type            "alsa"
        name            "ALSA Output"
#       device          "hw:0,0"        # optional
        mixer_type      "software"      # optional
#       mixer_device    "default"       # optional
#       mixer_control   "PCM"           # optional
#       mixer_index     "0"             # optional
#       auto_resample   "no"
#       auto_channels   "no"
#       auto_format     "no"
}

Tendo o mesmo comportamento problemático descrito por @flittermice : decepcionado:
O sistema é RPi2 executando uma nova instalação do Raspbian Stretch (9.1) com pulseaudio v10.0-1 + deb9u1, kernel 4.9.59+
Tenho lido artigos / tutoriais / tópicos relacionados, mas a reprodução do MPD trava conforme descrito acima, até que eu mate e reinicie o pulseaudio.

Alguém já encontrou uma solução para isso? : cross_fingers:: smile:

Encontrou algo interessante (talvez):
Quando pulseaudio trava (conforme descrito acima), emitir um comando "paplay" duas vezes (!) Continua a reprodução de áudio:
$ paplay /usr/share/sounds/alsa/Front_Center.wav

• Na primeira vez, o comando paplay expira (ou pode ser interrompido por Ctrl + C)
• Na segunda vez, o comando paplay funciona e agora o som do MPD é retomado.

Funciona por um período aleatório de tempo, depois volta ao comportamento de @flittermice : sob:

Eu deparei mais sobre esse problema e descobri que o uso de um recurso ALSA esotérico da Pulseaudio chamado "retrocesso" está causando o problema.
Infelizmente, não há opção de configuração para impedir que o PA use esse recurso.
Este branch o desativa permanentemente no código-fonte: https://github.com/strfry/pulseaudio/tree/no_rewind
Se você pode construí-lo e instalá-lo em seu sistema, verifique se isso resolve o seu problema.

Eu depurei ainda mais esse problema e descobri que o uso de um recurso ALSA esotérico da Pulseaudio
chamado de "retrocesso" está causando esse problema.
Infelizmente, não há opção de configuração para impedir que o PA use esse recurso.

Mas o pulso pode funcionar corretamente se você remover esse recurso?

Lembre-se de que parte da funcionalidade que ele oferece como servidor de som é a mixagem de sons que podem ser originados de vários aplicativos juntos.
E posso imaginar que, se você quiser permitir que novos aplicativos adicionem sons à mixagem instantaneamente, você precisa encontrar uma maneira de descartar parte do buffer existente.
Caso contrário, você só pode adicionar novo som no final do buffer e terá lag, o que o aplicativo pode não esperar. E o que pode ser um problema para alguns fins (por exemplo, vídeo com som)

@maxnet Uma correção adequada (a minha não é) fixaria a latência em um valor bastante baixo, o que elimina a necessidade de retrocesso, ao custo de uma carga de CPU / consumo de energia ligeiramente maior.
Funciona bem para meu aplicativo de baixa latência, para tocar música com MPD, pode ser um pouco chato não ter de retroceder (sem corrigir o PA para apenas fazer buffers de baixa latência).

Sempre tendo baixa latência, implicaria em pequenos buffers.
O que também não parece ideal para mim.

Diria que uma correção adequada seria no módulo do kernel ...

@strfry : a relação com o retrocesso do ALSA parece razoável. Quando pulseaudio fica "infeliz", geralmente termina nesta linha:

D: [alsa-sink-bcm2835 ALSA] source.c: Processando retrocesso ...

No entanto, concordo um pouco com @maxnet , e provavelmente há uma razão para ALSA fazer isso em primeiro lugar ...: wink:

Isso só não funciona no Raspberry Pi ou é um problema geral do pulseaudio + ALSA?
Ainda sendo um problema há mais de 3 anos, devemos relatar isso aos desenvolvedores pulseaudio / ALSA em vez de aqui?

@ pjotrek-b Não funciona apenas com a 'placa' de som integrada Raspberry PI. Usamos pulseaudio como servidor de som de rede com sucesso com placa de som USB por vários meses sem problemas.

Posso confirmar a declaração de @jekhor .
A mesma configuração funciona perfeitamente com minha placa de som USB (snd_usb_audio) no Raspberry Pi.

Como o arquivo de log diz: "E: [alsa-sink-bcm2835 ALSA] alsa-sink.c: Provavelmente este é um bug no driver ALSA '(null)'. Por favor, relate este problema para os desenvolvedores ALSA.". Alguém sabe como fazer isso?

@jekhor : Obrigado por esclarecer isso! :sorriso:

O que é intrigante agora é que sempre pensei que fosse assim:
application > pulseaudio > ALSA > driver > hardware

Em caso afirmativo, como os mesmos aplicativos que apresentam esse problema podem funcionar perfeitamente ao usar o ALSA diretamente?
application > ALSA > driver > hardware

Agora, se esse problema é específico da placa de som / chip integrado do RPi, por que esses problemas também não aparecem com o uso exclusivo do ALSA? :confuso:

@strfry : Encontrei um artigo bastante detalhado sobre "Retrocesso" na documentação do pulseaudio .

Eu li partes dele e não parece mais tão "esotérico" para mim agora. Já que você olhou seu código: Alguma idéia do que poderia fazer com que pulseaudio "travasse"?
Como mencionei acima, executar "paplay" duas vezes parece dar um "empurrãozinho" para voltar a trabalhar ...: smile:

@ pjotrek-b Claro que faz sentido, dados os objetivos de design da Pulseaudio. É "esotérico" no sentido de que 99% dos aplicativos ALSA normais nunca usarão o retrocesso e, portanto, acionarão um caminho menos testado no driver ALSA. Infelizmente, o Pulseaudio não tem a opção de desabilitar o uso desse recurso potencialmente problemático (como outro, por exemplo, programação baseada em cronômetro).
Não depurei os detalhes exatos, mas basicamente o Pulseaudio fica preso em um loop infinito, porque o ALSA falha em relatar corretamente quando é hora de gravar dados de áudio no dispositivo novamente.
Apesar das possibilidades de contornar isso no lado da Pulseaudio, este é um bug no driver ALSA.
Minha suspeita é que a emissão de novos fluxos irá gerar os eventos que o Pulseaudio está esperando quando travar.

@flittermice Eu acho que neste caso, o desenvolvedor ALSA responsável é alguém dos desenvolvedores do kernel Raspberry Pi que escreveu o driver snd_bcm2835, então este repositório seria o lugar certo para relatar isso.

Um exemplo de código simples que demonstra um comportamento claramente errado do ALSA ao usar o retrocesso provavelmente seria útil para os desenvolvedores do kernel ao examinar mais de perto este bug.

@ pjotrek-b Claro que faz sentido, dados os objetivos de design da Pulseaudio. É "esotérico" no sentido de que 99% dos aplicativos ALSA normais nunca usarão o retrocesso e, portanto, acionarão um caminho menos testado no driver ALSA. Infelizmente, o Pulseaudio não tem a opção de desabilitar o uso desse recurso potencialmente problemático (como outro, por exemplo, programação baseada em cronômetro).
Não depurei os detalhes exatos, mas basicamente o Pulseaudio fica preso em um loop infinito, porque o ALSA falha em relatar corretamente quando é hora de gravar dados de áudio no dispositivo novamente.
Apesar das possibilidades de contornar isso no lado da Pulseaudio, este é um bug no driver ALSA.
Minha suspeita é que a emissão de novos fluxos irá gerar os eventos que o Pulseaudio está esperando quando travar.

@flittermice Eu acho que neste caso, o desenvolvedor ALSA responsável é alguém dos desenvolvedores do kernel Raspberry Pi que escreveu o driver snd_bcm2835, então este repositório seria o lugar certo para relatar isso.

Um exemplo de código simples que demonstra um comportamento claramente errado do ALSA ao usar o retrocesso provavelmente seria útil para os desenvolvedores do kernel ao examinar mais de perto este bug.

Em caso afirmativo, como os mesmos aplicativos com esse problema podem funcionar perfeitamente ao usar o ALSA diretamente?

Normalmente, os aplicativos que usam o ALSA diretamente não precisam de retroceder.
Eles sabem exatamente que som desejam reproduzir nos próximos segundos e o enviam para o dispositivo de áudio.

É utilizado em situações de mudança de planos.
Se o Pulse já tiver enviado o áudio pelos próximos 2 segundos para o dispositivo e, de repente, um cliente Pulse diferente se conectar e quiser tocar o som também - sem ter que esperar que esses 2 segundos acabem primeiro - ele tem que avisar o som dispositivo para descartar o buffer anterior e substituí-lo por novos dados que tenham o som extra mixado.

Claro, se você usar buffers minúsculos que armazenam milissegundos em vez de segundos de áudio, seria possível fazer sem retrocesso.
No entanto, não acho que seja o preferido.
No Linux, não há garantias sobre a quantidade de tempo de CPU que qualquer aplicativo obtém, nem que ele é dividido igualmente, pois não é um sistema operacional de tempo real.
Se outro aplicativo estiver usando muito e o Pulse não tiver tempo suficiente para manter aquele minúsculo buffer preenchido o tempo todo, ele ficará insuficiente e seu som irá falhar.

Como mencionei acima, executar "paplay" duas vezes parece dar um "empurrãozinho" para voltar a trabalhar ...: smile:

O Áudio de pulso também fecha a conexão com o dispositivo de som 5 segundos após o último cliente que o usou se desconectar, se nenhum outro cliente se conectar durante esse tempo.
E reabre na próxima vez que um cliente quiser usá-lo.
Portanto, se houver tempo suficiente entre seus comandos, esse também pode ser o motivo pelo qual ele está funcionando novamente.

@strfry e @maxnet :
Muito obrigado por essas respostas detalhadas!

Alguém sabe se isso ainda é um problema no Raspbian mais recente (com kernel 4.14.y)?

Este problema será encerrado em 30 dias, a menos que outras interações sejam publicadas. Se você deseja que este problema permaneça aberto, por favor, adicione um comentário. Um problema fechado pode ser reaberto se solicitado.

Eu verificaria, mas atualmente não tenho tempo para testá-lo ...: decepcionado:
Para garantir: posso reabri-lo se testar depois de 30 dias e ainda houver um problema?

Embora eu tenha certeza de que não houve melhorias, não posso contribuir muito para esse bug em particular. Comprei uma placa de som USB externa com um chipset PCM2704 e agora estou feliz com o driver snd_usb_audio.
Usar a saída HDMI do raspi teria sido uma boa opção, mas meu raspi até se recusaria a inicializar com o cabo HDMI conectado ao receptor AV ... mas isso é outra história.

Fechando por falta de atividade. Solicite a reabertura se achar que o problema ainda é relevante.

Posso confirmar que isso acontece com meu Rasp Pi 3
Estou executando o ArchARM com kernel versão 4.14.69

Posso confirmar que isso ainda está acontecendo no meu RPI3:

Linux 4.14.71-v7+ #1145 SMP Fri Sep 21 15:38:35 BST 2018 armv7l GNU/Linux

Tentando usar mpd com pulseaudio recebo:

Nov 05 09:25:17 noise systemd[1]: Started Music Player Daemon.
Nov 05 09:25:19 noise pulseaudio[1567]: [pulseaudio] server-lookup.c: Unable to contact D-Bus: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
Nov 05 09:25:19 noise pulseaudio[1567]: [pulseaudio] main.c: Unable to contact D-Bus: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
Nov 05 09:25:20 noise pulseaudio[1567]: [alsa-sink-bcm2835 ALSA] alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write.
Nov 05 09:25:20 noise pulseaudio[1567]: [alsa-sink-bcm2835 ALSA] alsa-sink.c: Most likely this is a bug in the ALSA driver '(null)'. Please report this issue to the ALSA developers.
Nov 05 09:25:20 noise pulseaudio[1567]: [alsa-sink-bcm2835 ALSA] alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail.

Alguma chance de reabrirmos este problema?

Posso confirmar que isso acontece com meu Rasp Pi 3
Estou executando o ArchARM com kernel versão 4.14.69
Isso foi por causa da permissão errada, eu tenho funcionado.

@ l4rzy : você está nos deixando curiosos. Quais permissões?

@flittermice : Opa, não entendi a situação, já que comentei sobre isso por meses. Não se tratava de permissões.
Tentei configurar meu Raspberry Pi 3 para um servidor de áudio Pulse de rede local, funcionou perfeitamente, mas depois de um tempo sem reproduzir nada, o servidor de áudio Pulse desligou automaticamente. Mais tarde eu instalo o mpd para tocar música do SoundCloud, que sempre abre uma conexão com o Pulse e o mantém funcionando. Não é uma solução ruim, eu acho.

@ l4rzy : Trabalhar é o caminho a percorrer :-)

BTW: Você já tentou não carregar "module-suspend-on-idle" no default.pa?

módulo de carga-módulo-suspensão-em-inativo

@flittermice eu tentei. Não ajuda.

Pulseaudio ainda não está funcionando com snd_bcm2835. Você pode reabrir este problema, por favor?

Posso confirmar que também não está funcionando para mim. Tenho testado códigos diferentes e opções de compilação e não consigo fazê-los funcionar. Estou no ArchLinux ARM e todos os softwares mais novos. Fico feliz em ajudar a depurar, se possível.

Para mim, pelo que posso dizer, o problema vem do tamanho do buffer relatado pelo módulo bcm2835_alsa. O buffer de áudio relatado para o pulso é de 8.816 bits, ou apenas o suficiente para aproximadamente 1,56 ms de áudio de um fluxo de rede. Eu não sou um geek de hardware o suficiente para encontrar as especificações, mas algo parece errado aqui. De acordo com o próprio ALSA (ou seja, não o módulo de pulso), o tamanho do buffer é muito mais lógico de 131072 bits. Se eu fosse adivinhar, o pulso pensa que não pode manter o buffer cheio para o cartão e tenta retroceder porque está sendo informado que há um limite de software de 8816 bits ... mas talvez eu esteja muito errado aqui.

Acabei de ter o mesmo problema (é realmente irritante), @ JamesH65 você poderia reabri-lo para rastreá-lo posteriormente?

Hmmm ... Não consigo reproduzir isso com o Raspberry Pi 3 B v1.2 e o kernel 4.19.34 mais recente (atualizado por rpi-update para https://github.com/Hexxeh/rpi-firmware/commit/99c274691c07480762dcda91a0ebfe3c4f519307). Não tenho ideia do porquê, o driver parece não ter mudado desde 2016. Talvez algumas mudanças de firmware VC?

Olá, no Raspberry Pi 4 B v1.1, o kernel 5.3.0-1014 tem o mesmo problema com desvanecimento do som com pulseaudio v13.0. O som é perdido se uma saída estéreo for selecionada no pavucontrol. Existe alguma solução?

@acegallagher :

O buffer de áudio relatado para o pulso é de 8.816 bits, ou apenas o suficiente para aproximadamente 1,56 ms de áudio de um fluxo de rede.

Acho que isso ocorre porque o PulseAudio está detectando os coletores como Mono por padrão ( por causa desse problema ), e o tamanho do buffer padrão para eles é menor.
Tente atualizar o arquivo de configuração do perfil padrão do PA para que os coletores estéreo sejam criados, pois isso fará com que o PA crie coletores com device.buffering.buffer_size = "17632" , o que parece melhor!

@ olevenets2

Olá, no Raspberry Pi 4 B v1.1, o kernel 5.3.0-1014 tem o mesmo problema com desvanecimento do som com pulseaudio v13.0. O som é perdido se uma saída estéreo for selecionada no pavucontrol. Existe alguma solução?

Certifique-se de atualizar o arquivo de configuração do perfil padrão do PA para que a saída estéreo realmente funcione usando PA no RPI 4, e certifique-se de ter load-module module-udev-detect e não load-module module-alsa-sink em seu /etc/pulse/default.pa .