Pia de gagueira PulseAudio

12

Instalei o raspbian no meu Pi e configurei um coletor PulseAudio com a intenção de transmitir todo o áudio da minha área de trabalho para um Pi, acionando os alto-falantes.

Eu segui essa boa descrição: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=38&t=11124

A princípio, isso pareceu funcionar sem problemas. No entanto, o áudio enviado da área de trabalho está constantemente gaguejando no Pi, como se houvesse constantes interrupções de buffer com apenas algumas amostras ausentes no meio.

Passei o dia inteiro tentando encontrar a causa, mas sem sucesso. A configuração básica é:

conexão LAN com fio
raspbian pi mais recente (26 de setembro de 2013) com as atualizações de firmware mais recentes
PulseAudio 2.0 em ambos os lados (desktop Ubuntu)
Reprodução através de mplayer, totem, ffplay
transmissão de rede via module-native-protocol-tcp

Isto é o que eu tentei:

A reprodução de áudio diretamente no Pi funciona perfeitamente.
A transmissão para outros computadores (desktop) funciona bem.
O envio de áudio com uma conexão direta (especificando $ PULSE_SERVER) funciona muito bem com muito pouca gagueira, mas ainda propenso ao Problema-2 (veja abaixo)
O envio de áudio via tunelamento PulseAudio da área de trabalho oferece gagueira constante
Aumentar prioridades / agendamento em tempo real ... não ajudou
Fixar a taxa de amostragem para 48 kHz ... não ajudou
Definir o algoritmo de reamostragem como "trivial" ... não ajudou
Ajustar fragmentos padrão / tamanho do fragmento ... não ajudou

Não consigo encontrar nenhuma indicação de problema nos logs do PulseAudio (mostrados a partir do momento em que iniciei a reprodução):

D: [alsa-sink] protocol-native.c: Requesting rewind due to end of underrun.
D: [alsa-sink] sink-input.c: Requesting rewind due to uncorking
D: [pulseaudio] sink.c: Suspend cause of sink alsa_output.platform-bcm2835_AUD0.0.analog-stereo is 0x0000, resuming
I: [alsa-sink] alsa-sink.c: Trying resume...
I: [alsa-sink] alsa-util.c: cannot disable ALSA period wakeups
D: [alsa-sink] alsa-util.c: Maximum hw buffer size is 341 ms
D: [alsa-sink] alsa-util.c: Set buffer size first (to 16384 samples),  period size second (to 16384 samples).
I: [alsa-sink] alsa-util.c: ALSA period wakeups were not disabled
D: [alsa-sink] alsa-sink.c: Latency set to 25.00ms
D: [alsa-sink] alsa-sink.c: hwbuf_unused=60736
D: [alsa-sink] alsa-sink.c: setting avail_min=15665
I: [alsa-sink] alsa-sink.c: Time scheduling watermark is 15.00ms
I: [alsa-sink] alsa-sink.c: Resumed successfully...
I: [alsa-sink] alsa-sink.c: Starting playback.
D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
D: [pulseaudio] module-suspend-on-idle.c: Sink alsa_output.platform-bcm2835_AUD0.0.analog-stereo becomes busy.
D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
D: [alsa-sink] ratelimit.c: 115 events suppressed
D: [alsa-sink] alsa-sink.c: Wakeup from ALSA!
... no more output, but stuttering continues ...

Problema 2: como dito acima, posso obter um áudio bastante bom com uma conexão direta. No entanto, após alguns pulos no fluxo (usando o mplayer), o servidor PulseAudio trava e não reproduz nenhum áudio. Às vezes, pode ser revivido reiniciando o mplayer. Às vezes, ele trava tanto que o PulseAudio precisa ser reiniciado. Às vezes, até trava quando apenas altero o nível do volume.

De acordo com os documentos do PulseAudio, a vantagem de uma conexão direta sobre uma conexão com túnel é ter um melhor controle de buffer, o que parece indicar por que obtenho um bom áudio com a conexão direta: http://www.freedesktop.org/wiki/Software / PulseAudio / Documentação / Usuário / Rede /

Estou sem idéias agora. O que poderia causar a gagueira e o Problema 2? Apenas uma idéia de como proceder a depuração também seria apreciada.

networking audio

— farindk
fonte

Como você tocou o áudio diretamente? Não tive problemas com o aplay, mas o paplay gagueja e ecoa terrivelmente.

— John La Rooy

Usei mplayer, totem, madplay, ... Mas o fato de diferentes jogadores se comportarem de maneira diferente apóia meu palpite de que parece ser um problema de software com buffer de dados. Alguns jogadores empurram mais dados antes do tempo real do que outros.

— precisa saber é

Estou tendo problemas apenas tocando ondas senoidais . Acho que vou precisar resolver isso antes que eu possa tentar transmitir pela LAN.

— John La Rooy

6

tsched_buffer_sizee tsched_buffer_watermarkforam as configurações que fizeram o trabalho para mim.

Eu executar o meu PulseAudio como uma instância do sistema, de modo que a configuração está em /etc/pulse/system.pa. Se você estiver usando uma instância de sessão em vez disso, em seguida, a configuração estará em /etc/pulse/default.pa.

Este é o padrão:

### Automatically load driver modules depending on the hardware available
.ifexists module-udev-detect.so
load-module module-udev-detect
.else
### Use the static hardware detection module (for systems that lack udev/hal  support)
load-module module-detect
.endif

Substituí-o por: (isto é, comentei)

### Automatically load driver modules depending on the hardware available
.ifexists module-udev-detect.so
#load-module module-udev-detect
.else
### Use the static hardware detection module (for systems that lack udev/hal  support)
#load-module module-detect
.endif

Então eu adicionei a seguinte linha:

load-module module-alsa-card device_id=0 tsched=true tsched_buffer_size=1048576 tsched_buffer_watermark=262144

Consulte http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/#index6h3

— Phil
fonte

Bom ponto. Eu tentei, mas não ajudou. Mesmo com tamanhos de buffer muito maiores. O envio de áudio por uma conexão direta, configurando PULSE_SERVER para o Pi fornece áudio limpo, mas apenas a alteração do volume congelará a conexão. O áudio via tunelamento ainda dá a gagueira. Meu palpite é que esse é realmente um problema do PulseAudio, porque com esse tamanho de buffer grande (usei 4 MB), é preciso observar que o áudio é decodificado com bastante antecedência no início de um arquivo. Mas não é. Portanto, deve haver algo que diminui a velocidade do refil.

— farindk

Correndo para o mesmo tipo de problemas. No meu caso particular, o PULSE_SERVER + mplayer funciona como um encanto, enquanto o PULSE_SERVER + clementina (que eu acredito que esteja usando o gstreamer) gagueja terrivelmente. Alguma idéia do que difere entre os dois?

— precisa saber é o seguinte

@Protzenko: Meu palpite, sem procurar nenhuma fonte, é que o mplayer pode enviar dados até o PulseAudio estar bloqueando, enquanto o gstreamer pode enviar dados com uma referência em tempo real. Isso significaria que os buffers são muito mais preenchidos no caso anterior e, consequentemente, há um atraso maior.

— farindk

Eu estou vendo o mesmo problema PULSE_SERVER + ffmpeg bem, PULSE_SERVER + mpd persianas e underruns implícitos

— Reimundo Heluani

3

O ponto principal é que você deve usá-lo module-tunnel-sink-new, mas também deve fazer algumas outras alterações para obter um áudio de rede sem interrupções no raspberry pi 1.

Execute o pulseaudio no raspberry pi com prioridade em tempo real:

pulseaudio --start --high-priority=yes --realtime=yes

Vamos usar o termo remetente para indicar o computador que envia o fluxo ao seu raspberry pi.

Definir default-fragmentse default-fragment-size-msecem daemon.confpelo remetente para estes valores:

default-fragments = 8
default-fragment-size-msec = 12

Use module-tunnel-sink-newemitindo este comando no remetente (assumindo que o nome do host do seu raspberry pi seja RP1 e você tenha o mDNS trabalhando em sua rede local. Caso contrário, basta usar o endereço IP do seu raspberry pi).

pactl load-module module-tunnel-sink-new server=RP1.local

Com essas configurações, eu recebo áudio sem interrupções de um raspberrypi 1 em uma rede sem fio operando a 54 Mbps (Na minha configuração, o remetente usa ethernet e o RP1 está usando wlan). Na verdade, funciona mesmo quando o remetente e o raspberrypi estão usando a WLAN, pelo menos se não houver outros dispositivos na rede sem fio.

— Hans Ekbrand
fonte

Funciona muito bem até agora. Eu descobri que para o meu Pi3 (com um software / debian um pouco mais recente) tive que mudar outra coisa para que as configurações de "fragmentos padrão" fossem escolhidas. (ou seja, algo definindo tsched=0, consulte wiki.archlinux.org/index.php/PulseAudio/… )

— rien333

Se você ainda sofre de gagueira, o wiki do arch também recomenda a alteração do protocolo de streaming rtp

— rien333

1

você consultou esta página:

http://manpages.ubuntu.com/manpages/lucid/man5/pulse-daemon.conf.5.html

CONFIGURAÇÕES DE FRAGMENTO PADRÃO

   Some hardware drivers  require  the  hardware  playback  buffer  to  be
   subdivided  into  several  fragments.  It  is  possible to change these
   buffer metrics for machines with high  scheduling  latencies.  Not  all
   possible  values  that  may  be  configured  here  are available in all
   hardware. The driver will to find the nearest setting supported. Modern
   drivers that support timer-based scheduling ignore these options.

   default-fragments= The default number of fragments. Defaults to 4.

   default-fragment-size-msec=The  duration of a single fragment. Defaults
   to 25ms (i.e. the total buffer is thus 100ms long).

— Alter Schwede
fonte

Sim, tentei isso, mas não ajudou. Como mencionei, a reprodução de áudio no próprio dispositivo funciona bem. Presumo que seja um problema de protocolo de rede com o encapsulamento PulseAudio. Até o protocolo de conexão direta funciona bem. Agora mudei para um simples hardware de streaming Bluetooth, confiável e usando o RPi para outras coisas.

— farindk

1

Para se livrar de problemas de gagueira ou de tempo limite, tente um downgrade do FW:

sudo rpi-update eeb2e51c3e08cd5efa4246aa8dc54a09b25ada12

— user13034
fonte

1

AVISO Esteja ciente do que o rpi-updateuso dessa maneira pode fazer ao seu sistema.

— precisa saber é o seguinte

@earthmeLon você poderia pelo menos dar uma referência ou tentar nos informar o que usar rpi-updatedesta forma pode fazer para os nossos sistemas de ...

— user11171

Certifique-se Leia o manual , e fazer alguma pesquisa para compreender como isso afeta o seu sistema e quaisquer perigos potenciais.

— earthmeLon

0

Reconheci que esse problema pode estar relacionado à versão do kernel. Depois de atualizar de 3.6.11 para 3.12.0, recebi constantemente essas falhas. Um downgrade de volta para 3.6.11 resolveu o problema para mim.

— Manuel Faux
fonte

0

Estive lendo esta página algumas vezes ... Também fiquei frustrado com a gagueira da combinação RaspberryPi-pulseaudio-network. Pesquisei um pouco mais e encontrei uma página em que encontrei parte da solução:

=> Desative o módulo suspenso no modo inativo no default.pa (ou system.pa).

Eis que a gagueira desapareceu!

Agora, o único problema é que, depois de um tempo (10 a 20 segundos), a reprodução trava: - /

Alguma sugestão?

— Jørn Christensen
fonte