Tartamudeo del fregadero PulseAudio

12

He instalado raspbian en mi Pi y configuré un receptor PulseAudio con la intención de transmitir todo el audio de mi escritorio a un Pi, conduciendo los altavoces.

Seguí esta bonita descripción: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=38&t=11124

Al principio, esto parecía funcionar sin problemas. Sin embargo, el audio enviado desde el escritorio está tartamudeando constantemente en el Pi, como si hubiera subestimaciones constantes del búfer con solo algunas muestras faltantes en el medio.

Pasé todo el día tratando de encontrar la causa, pero fue en vano. La configuración básica es:

conexión LAN cableada
raspbian pi más reciente (26 de septiembre de 2013) con las últimas actualizaciones de firmware
PulseAudio 2.0 en ambos lados (escritorio Ubuntu)
Reproducción a través de mplayer, totem, ffplay
transmisión de red a través de module-native-protocol-tcp

Esto es lo que probé:

Reproducir audio directamente en el Pi funciona perfectamente.
La transmisión a otras computadoras (de escritorio) funciona bien.
El envío de audio con una conexión directa (especificando $ PULSE_SERVER) funciona bastante bien con muy poco tartamudeo, pero sigue siendo propenso al problema 2 (ver más abajo)
El envío de audio a través del túnel de PulseAudio en el escritorio proporciona un tartamudeo constante
El aumento de prioridades / programación en tiempo real ... no ayudó
Fijar la frecuencia de muestreo a 48 kHz ... no ayudó
Establecer el algoritmo de remuestreo en "trivial" ... no ayudó
Ajustar fragmentos predeterminados / tamaño de fragmento ... no ayudó

No puedo encontrar ninguna indicación de un problema en los registros de PulseAudio (que se muestran desde el momento en que comencé la reproducción):

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 se dijo anteriormente, puedo obtener un audio bastante bueno con una conexión directa. Sin embargo, después de algunos saltos dentro de la transmisión (usando mplayer), el servidor PulseAudio se cuelga y no reproduce ningún audio. A veces se puede revivir reiniciando mplayer. A veces se cuelga tanto que PulseAudio tiene que reiniciarse. A veces incluso se cuelga cuando solo cambio el nivel de volumen.

Según los documentos de PulseAudio, la ventaja de una conexión directa sobre una conexión en túnel es tener un mejor control de almacenamiento en búfer, lo que parece indicar por qué obtengo un buen audio con la conexión directa: http://www.freedesktop.org/wiki/Software / PulseAudio / Documentation / User / Network /

Estoy sin ideas ahora. ¿Qué podría causar la tartamudez y el problema 2? Solo una idea de cómo proceder a la depuración también sería apreciada.

networking audio

— farindk
fuente

¿Cómo reprodujiste el audio directamente? No he tenido problemas con el juego, pero el juego tartamudea y hace eco terriblemente.

— John La Rooy

Utilicé mplayer, totem, madplay, ... Pero el hecho de que diferentes jugadores se comporten de manera diferente respalda mi suposición de que parece ser un problema de software con el almacenamiento en búfer de datos. Algunos jugadores empujan más datos antes que el tiempo real que otros.

— farindk

Estoy teniendo problemas solo jugando ondas sinusoidales . Creo que tendré que resolver eso antes de poder intentar la transmisión a través de la LAN.

— John La Rooy

6

tsched_buffer_sizey tsched_buffer_watermarkfueron los ajustes que lo hicieron funcionar para mí.

Ejecuto mi PulseAudio como una instancia del sistema, por lo que la configuración está en /etc/pulse/system.pa. Si está utilizando una instancia de sesión, entonces la configuración estará en /etc/pulse/default.pa.

Este es el valor predeterminado:

### 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

Lo reemplacé con esto: (es decir, lo comenté)

### 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

Luego agregué la siguiente línea:

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

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

— Phil
fuente

Buen punto. Lo intenté, pero no sirvió de nada. Incluso con tampones mucho más grandes. El envío de audio a través de una conexión directa configurando PULSE_SERVER al Pi proporciona un audio limpio, pero solo cambiando el volumen eventualmente se congelará la conexión. El audio a través de túneles todavía da el tartamudeo. Supongo que esto es realmente un problema de PulseAudio, porque con ese gran tamaño de búfer (usé 4 MB), uno debería ver que el audio se decodifica con mucha anticipación al comienzo de un archivo. Pero no lo es. Entonces debe haber algo que frene la recarga.

— farindk

Encontrarse con el mismo tipo de problemas. En mi caso particular, PULSE_SERVER + mplayer funciona de maravilla, mientras que PULSE_SERVER + clementine (que creo que está usando gstreamer) tartamudea terriblemente. ¿Alguna idea de lo que difiere entre los dos?

— Jonathan Protzenko

@Protzenko: Supongo que sin mirar ninguna fuente es que mplayer podría enviar datos hasta que PulseAudio se esté bloqueando, mientras que gstreamer podría enviar datos sincronizados por una referencia en tiempo real. Eso significaría que los buffers están mucho más llenos en el primer caso y, en consecuencia, hay un retraso mayor.

— farindk

Estoy viendo el mismo problema PULSE_SERVER + ffmpeg bien, PULSE_SERVER + persianas mpd y underruns implícitos

— Reimundo Heluani

3

El punto principal es que debe usar module-tunnel-sink-new, pero también debe hacer algunos otros cambios para obtener audio de red sin interrupciones en la frambuesa pi 1.

Ejecute pulseaudio en la frambuesa pi con prioridad en tiempo real:

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

Usemos el término remitente para denotar la computadora que envía la transmisión a su raspberry pi.

Establezca default-fragmentsy default-fragment-size-msecentre daemon.confen el remitente estos valores:

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

Úselo module-tunnel-sink-newemitiendo este comando en el remitente (suponiendo que el nombre de host de su Raspberry Pi es RP1 y tiene mDNS trabajando en su red local. De lo contrario, solo use la dirección IP de su Raspberry Pi).

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

Con esta configuración, obtengo audio sin interrupciones de un raspberrypi 1 a través de una red inalámbrica que funciona a 54 Mbps (en mi configuración, el remitente usa ethernet y RP1 usa wlan). En realidad, funciona incluso cuando el remitente y raspberrypi están usando wlan, al menos si no hay otros dispositivos en la red inalámbrica.

— Hans Ekbrand
fuente

Funciona muy bien hasta ahora. Encontré que para mi Pi3 (con un debian / software algo más nuevo) tuve que cambiar algo más para que se recogiera la configuración de "fragmentos predeterminados". (a saber, configuración de algo tsched=0, consulte wiki.archlinux.org/index.php/PulseAudio/… )

— rien333

Si aún experimenta tartamudeo, el arch wiki también recomienda cambiar al protocolo de transmisión rtp

— rien333

1

¿Revisaste esta página?

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

CONFIGURACIÓN DE FRAGMENTO POR DEFECTO

   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
fuente

Sí, lo intenté, pero no sirvió de nada. Como mencioné, la reproducción de audio en el dispositivo en sí funciona bien. Supongo que es un problema de protocolo de red con el túnel de PulseAudio. Incluso el protocolo de conexión directa funciona bien. Ahora he cambiado a un hardware de transmisión Bluetooth simple, que es confiable y que usa el RPi para otras cosas.

— farindk

1

Para deshacerse de los problemas de tartamudeo o tiempo de espera, intente una degradación de FW:

sudo rpi-update eeb2e51c3e08cd5efa4246aa8dc54a09b25ada12

— usuario13034
fuente

1

ADVERTENCIA Tenga en cuenta qué rpi-updateuso de esta manera puede hacer a su sistema.

— earthmeLon

@earthmeLon que podría al menos dar una referencia o tratar de informarnos lo que el uso rpi-updatede esta forma se puede hacer para nuestros sistemas ...

— user11171

Asegúrese de leer el Manual e investigue un poco para comprender cómo afecta esto a su sistema y cualquier peligro potencial.

— earthmeLon

0

Reconocí que este problema podría estar relacionado con la versión del kernel. Después de actualizar de 3.6.11 a 3.12.0 recibí constantemente esos underruns. Una degradación a 3.6.11 me resolvió el problema.

— Manuel Faux
fuente

0

He estado leyendo esta página un par de veces ... También me he sentido frustrado con la tartamudez de la combinación RaspberryPi-pulseaudio-network. Busqué un poco más y encontré una página donde encontré una parte de la solución:

=> Deshabilite el módulo-suspender-en-inactivo en default.pa (o system.pa).

¡Mira, la tartamudez ha desaparecido!

Ahora el único problema es que después de un tiempo (10 a 20 segundos) la reproducción se bloquea: - /

¿Alguna sugerencia?

— Jørn Christensen
fuente