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.
fuente
Respuestas:
tsched_buffer_size
ytsched_buffer_watermark
fueron 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:
Lo reemplacé con esto: (es decir, lo comenté)
Luego agregué la siguiente línea:
Ver http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/#index6h3
fuente
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.Usemos el término remitente para denotar la computadora que envía la transmisión a su raspberry pi.
default-fragments
ydefault-fragment-size-msec
entredaemon.conf
en el remitente estos valores:module-tunnel-sink-new
emitiendo 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).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.
fuente
tsched=0
, consulte wiki.archlinux.org/index.php/PulseAudio/… )¿Revisaste esta página?
http://manpages.ubuntu.com/manpages/lucid/man5/pulse-daemon.conf.5.html
CONFIGURACIÓN DE FRAGMENTO POR DEFECTO
fuente
Para deshacerse de los problemas de tartamudeo o tiempo de espera, intente una degradación de FW:
fuente
rpi-update
uso de esta manera puede hacer a su sistema.rpi-update
de esta forma se puede hacer para nuestros sistemas ...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.
fuente
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?
fuente