PulseAudio sinkt stotternd

12

Ich habe Raspbian auf meinem Pi installiert und eine PulseAudio-Senke konfiguriert, um alle Audiodaten von meinem Desktop auf einen Pi zu streamen und die Lautsprecher anzutreiben.

Ich folgte dieser schönen Beschreibung: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=38&t=11124

Zunächst schien dies ohne Probleme zu funktionieren. Das vom Desktop gesendete Audio stottert jedoch ständig auf dem Pi, als ob es konstante Pufferunterläufe gäbe, wobei nur ein paar Samples dazwischen fehlen.

Ich habe den ganzen Tag versucht, die Ursache zu finden, aber ohne Erfolg. Das Grundsetup ist:

Kabelgebundene LAN-Verbindung
Neueste Raspbian Pi (26. September 2013) mit den neuesten Firmware-Updates
PulseAudio 2.0 auf beiden Seiten (Ubuntu-Desktop)
Wiedergabe über mplayer, totem, ffplay
netzwerkübertragung via module-native-protocol-tcp

Das habe ich versucht:

Das Abspielen von Audio direkt auf dem Pi funktioniert einwandfrei.
Das Streamen auf andere (Desktop-) Computer funktioniert einwandfrei.
Das Senden von Audiodaten mit einer direkten Verbindung (Angabe von $ PULSE_SERVER) funktioniert recht gut mit sehr wenig Ruckeln, ist aber immer noch anfällig für Problem-2 (siehe unten).
Senden von Audio über den Desktop PulseAudio-Tunneln sorgt für ein konstantes Ruckeln
Erhöhen der Prioritäten / Echtzeitplanung ... hat nicht geholfen
Die Abtastrate auf 48 kHz festzulegen ... hat nicht geholfen
Das Setzen des Resampling-Algorithmus auf "trivial" ... hat nicht geholfen
Das Anpassen von Standard-Fragmenten / Fragment-Größe ... hat nicht geholfen

Ich kann keine Hinweise auf ein Problem in den PulseAudio-Protokollen finden (angezeigt ab dem Zeitpunkt, an dem ich mit der Wiedergabe begonnen habe):

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

Problem 2: Wie oben gesagt, kann ich mit einer direkten Verbindung ganz ok Audio bekommen. Nach einigen Sprüngen im Stream (mit mplayer) bleibt der PulseAudio-Server jedoch hängen und gibt überhaupt kein Audio wieder. Manchmal kann es durch einen Neustart von mplayer wiederbelebt werden. Manchmal hängt es so stark, dass PulseAudio neu gestartet werden muss. Manchmal hängt es sogar, wenn ich nur die Lautstärke ändere.

Laut den PulseAudio-Dokumenten besteht der Vorteil einer direkten Verbindung gegenüber einer getunnelten Verbindung in einer besseren Puffersteuerung. Dies scheint darauf hinzudeuten, warum ich mit der direkten Verbindung gute Audiodaten erhalte: http://www.freedesktop.org/wiki/Software / PulseAudio / Dokumentation / Benutzer / Netzwerk /

Ich habe jetzt keine Ideen mehr. Was könnte das Ruckeln und Problem 2 verursachen? Nur eine Idee, wie das Debuggen weitergehen soll, wäre ebenfalls wünschenswert.

networking audio

— farindk
quelle

Wie hast du den Ton direkt abgespielt? Ich hatte keine Probleme mit Aplay, aber Paplay stottert und hallt fürchterlich.

— John La Rooy

Ich habe mplayer, totem, madplay, ... verwendet. Die Tatsache, dass sich verschiedene Spieler unterschiedlich verhalten, stützt meine Vermutung, dass es sich anscheinend um ein Softwareproblem bei der Datenpufferung handelt. Einige Player stellen mehr Daten in Echtzeit zur Verfügung als andere.

— Farindk

Ich habe Probleme damit, nur Sinuswellen zu spielen . Ich denke, ich muss das lösen, bevor ich versuchen kann, über das LAN zu streamen.

— John La Rooy

6

tsched_buffer_sizeund tsched_buffer_watermarkwaren die Einstellungen, die es für mich arbeiten ließen.

Ich führe mein PulseAudio als Systeminstanz aus, die Konfiguration befindet sich also in /etc/pulse/system.pa. Wenn Sie stattdessen eine Sitzungsinstanz verwenden, befindet sich die Konfiguration in /etc/pulse/default.pa.

Dies ist die Standardeinstellung:

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

Ich habe es durch folgendes ersetzt: (dh auskommentiert)

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

Dann habe ich folgende Zeile hinzugefügt:

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

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

— Phil
quelle

Guter Punkt. Ich habe es versucht, aber es hat nicht geholfen. Auch bei viel größeren Puffergrößen. Wenn Sie Audio über eine direkte Verbindung senden, indem Sie PULSE_SERVER auf den Pi setzen, erhalten Sie sauberes Audio. Wenn Sie jedoch nur die Lautstärke ändern, wird die Verbindung möglicherweise unterbrochen. Audio via Tunnel gibt immer noch das Ruckeln. Ich vermute, dass dies wirklich ein PulseAudio-Problem ist, denn mit den großen Puffergrößen (ich habe 4 MB verwendet) sollte man sehen, dass das Audio zu Beginn einer Datei weit im Voraus dekodiert wird. Aber es ist nicht. Es muss also etwas geben, das die Nachfüllung verlangsamt.

— Farindk

Laufen in die gleiche Art von Problemen. In meinem speziellen Fall funktioniert PULSE_SERVER + mplayer wie ein Zauber, während PULSE_SERVER + Clementine (von der ich glaube, dass sie gstreamer verwendet) fürchterlich ruckelt. Irgendeine Idee, was sich zwischen den beiden unterscheidet?

— Jonathan Protzenko

@Protzenko: Ich vermute, ohne auf eine Quelle zu achten, dass mplayer möglicherweise Daten pusht, bis PulseAudio blockiert, während gstreamer möglicherweise Daten sendet, die durch eine Echtzeitreferenz getaktet werden. Das würde bedeuten, dass die Puffer im ersteren Fall viel mehr gefüllt sind und folglich eine größere Verzögerung vorliegt.

— Farindk

Ich sehe das gleiche Problem PULSE_SERVER + ffmpeg fein, PULSE_SERVER + mpd Fensterläden und implizite

— Unterläufe

3

Der wichtigste Punkt ist, dass Sie verwenden müssen module-tunnel-sink-new, aber Sie müssen auch ein paar andere Änderungen vornehmen, um ruckelfreies Netzwerk-Audio auf dem Himbeer-Pi 1 zu erhalten.

Führen Sie pulseaudio auf dem Himbeer-Pi mit Echtzeitpriorität aus:

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

Verwenden wir den Begriff Absender , um den Computer zu bezeichnen, der den Stream an Ihren Himbeer-Pi sendet.

Stellen default-fragmentsund default-fragment-size-msecin daemon.confan Absender auf diese Werte:

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

Verwenden Sie module-tunnel-sink-newdiesen Befehl beim Absender (vorausgesetzt, der Hostname Ihres Himbeer-Pi ist RP1 und Sie haben mDNS in Ihrem lokalen Netzwerk. Andernfalls verwenden Sie einfach die IP-Adresse Ihres Himbeer-Pi).

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

Mit diesen Einstellungen erhalte ich ruckelfreies Audio von einem Raspberrypi 1 über ein drahtloses Netzwerk mit einer Geschwindigkeit von 54 Mbit / s (In meinem Setup verwendet der Absender Ethernet und RP1 verwendet WLAN). Tatsächlich funktioniert es sogar, wenn sowohl der Absender als auch raspberrypi wlan verwenden, zumindest wenn sich keine anderen Geräte im drahtlosen Netzwerk befinden.

— Hans Ekbrand
quelle

Funktioniert soweit super. Ich habe festgestellt, dass ich für mein Pi3 (mit einem etwas neueren Debian / einer neueren Software) etwas anderes ändern musste, damit die "Standard-Fragmente" -Einstellungen übernommen wurden. (Nämlich etwas Einstellung tsched=0, siehe wiki.archlinux.org/index.php/PulseAudio/… )

— Rien333

Wenn Sie immer noch stottern, empfiehlt das Arch-Wiki auch, auf das RTP-Streaming-Protokoll umzusteigen

— rien333

1

Hast du diese Seite überprüft:

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

STANDARD FRAGMENT EINSTELLUNGEN

   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
quelle

Ja, das habe ich versucht, aber es hat nicht geholfen. Wie bereits erwähnt, funktioniert die Audiowiedergabe auf dem Gerät selbst einwandfrei. Ich gehe davon aus, dass es ein Netzwerkprotokollproblem mit dem PulseAudio-Tunneling ist. Auch das Direktverbindungsprotokoll funktioniert gut. Ich habe jetzt auf eine einfache Bluetooth-Streaming-Hardware umgestellt, die zuverlässig ist und das RPi für andere Dinge verwendet.

— Farindk

1

Versuchen Sie ein FW-Downgrade, um Stottern oder Timeout-Probleme zu vermeiden:

sudo rpi-update eeb2e51c3e08cd5efa4246aa8dc54a09b25ada12

— user13034
quelle

1

WARNUNG Beachten Sie, welche rpi-updateAuswirkungen diese Vorgehensweise auf Ihr System haben kann.

— EarthMeLon

@earthmeLon Sie könnten zumindest eine Referenz angeben oder versuchen, uns mitzuteilen, was die Verwendung rpi-updateauf diese Weise mit unseren Systemen

— bewirken

Achten Sie darauf, das Handbuch zu lesen , und einige der Forschung zu verstehen , wie das System und mögliche Gefahren beeinflusst.

— EarthMeLon

0

Ich habe erkannt, dass dieses Problem möglicherweise mit der Kernel-Version zusammenhängt. Nach dem Upgrade von 3.6.11 auf 3.12.0 habe ich ständig diese Unterschreitungen erhalten. Ein Downgrade auf 3.6.11 löste das Problem für mich.

— Manuel Faux
quelle

0

Ich habe diese Seite ein paar Mal gelesen ... Ich war auch frustriert über das Stottern der RaspberryPi-Pulseaudio-Netzwerkkombination. Ich habe ein bisschen mehr gesucht und eine Seite gefunden, auf der ich einen Teil der Lösung gefunden habe:

=> Deaktiviere das Modul-Suspend-On-Idle in der default.pa (oder system.pa).

Siehe, das Stottern ist verschwunden!

Jetzt ist das einzige Problem, dass die Wiedergabe nach einer Weile (10 bis 20 Sekunden) hängen bleibt: - /

Irgendwelche Vorschläge?

— Jørn Christensen
quelle