RTP, MPD und Sound streamen

[scientific]

OK.
Werd ich dann mal testen.
Aber ist da das streamen von einem zu mehreren usern möglich? Ich glaub mich zu erinnern, dass das der Grund war, warum ich RTP gewählt habe...

[smutbert]

stimmt das ginge nur mit Umwegen:

Man hätte mehrere Pulseaudio-Server und für jeden davon hätte man am Client den oder die zugehörigen Senken, die man dann für die gleichzeitige Wiedergabe mit module-combine-sink zu einer Senke zusammenfassen müsste.

[scientific]

Da teste ich doch lieber mit RTP weiter...
Und vor allem muss ich mich in die Multicast-Geschichte besser einarbeiten.
Ich vermute mal, dass ich eine Multicast-Route für lo anlegen muss, die ich gezielt mit einem RTP-Stream von pulseaudio des mpd ansteuere, und einen zweiten Stream für das Streaming ins Netz...

Ich denke mal, wenn ich hier ein vernünftiges Setup zusammenbringe, ist das auch für viele andere mpd-Nutzer interessant.
Lg scientific

[scientific]

So wie es jetzt aussieht, hab ich endlich mein Setup erfolgreich fertiggestellt.

Ich schalte lo in den Multicast-Modus und setze eine Route darauf.

Code: Alles auswählen

# cat network-multicast-lo.service 
[Unit]
Description=Configure loopback-interface for multicast (mpd-RTP-stream)

[Service]
Type=oneshot
ExecStart=/sbin/ifconfig lo multicast
ExecStart=/sbin/route add -net 224.0.0.0 netmask 240.0.0.0 dev lo
#ExecStart=/sbin/route add 224.0.0.56 netmask 255.255.255.0 dev lo

[Install]
WantedBy=basic.target

Für mpd habe ich unter /var/lib/mpd/.config/pulse/default.pa folgendes eingetragen:

Code: Alles auswählen

# cat /var/lib/mpd/.config/pulse/default.pa 
#! /usr/bin/pulseaudio -nF

load-module module-native-protocol-unix
load-module module-suspend-on-idle timeout=1

#.ifexists module-udev-detect.so
#load-module module-udev-detect tsched=0
#.else

load-module module-null-sink sink_name=rtp_localhost
#load-module module-rtp-send source=rtp.monitor loop=1 source_ip=127.0.0.1 destination_ip=224.0.0.56
load-module module-rtp-send source=rtp_localhost.monitor rate=48000 channels=2 format=s16be port=46102 loop=1 source_ip=127.0.0.1 destination_ip=224.0.0.56
set-default-sink rtp_localhost

#load-module module-null-sink sink_name=rtp
#load-module module-rtp-send source=rtp.monitor loop=1 source_ip=127.0.0.1 destination_ip=224.0.0.56
#load-module module-rtp-send source=rtp.monitor rate=48000 channels=2 format=s16be port=46102 loop=1 source_ip=127.0.0.1 destination_ip=224.0.0.57
#set-default-sink rtp

load-module module-zeroconf-publish

Und in /etc/pulse/default.pa habe ich zur Standardconfig lediglich diese Zeile noch eingefügt:

Code: Alles auswählen

.ifexists module-combine-sink.so
.fail
load-module module-combine-sink sink_name=combined_sys sink_properties="device.description='System-combined-sink'"
.nofail
.endif


### Load the RTP receiver module (also configured via paprefs, see above)
#load-module module-rtp-recv sap_address=224.0.0.56 sink=combined_sys
load-module module-rtp-recv sink=combined_sys

.fail
set-default-sink combined_sys
.nofail

Die Musik spielt damit unabhängig von einer aktiven Netzwerkverbindung und bei allen eingeloggten Usern incl. GDM-Anmeldebildschirm.
Allerdings bei jedem User untschiedlich gepuffert... und zeitversetzt. Manchmal werden die Latenzzeiten, bis der MPD reagiert (Pause/Play) extrem lange (viele Sekunden), und einem Bug von Pulseaudio bin ich auch auf der Spur (queue overrun) bzw. damit auf den Leim gegangen.

Und die unterschiedlichen pa-Instanzen krallen sich das Bluetooth-Device (so ich eines aktiviere) und verursacht so ein vollkommenes Verhindern eines Erkennens des Gerätes (z.B. Handy) oder das aktivieren/Pairing bzw. connect zum Audioprofil wird für den User (der nicht gdm oder mpd ist) unmöglich. Das ist aber wahrscheinlich eine andere Baustelle und wird nicht so einfach zum Lösen sein. (Als Workaround für das Headset-Problem wird im ArchLinux- und Ubuntu-Forum das Deaktivieren von PA für GDM genannt - was aber bei meinem Setup nicht infrage kommt (Ich will ja ohne eingeloggt zu sein auch Musik hören, weil ich mpd per Handy fernsteuere)

lg scientific

[scientific]

Diese Latenzen finde ich nach wie vor sehr störend... Und ich bin jetzt nochmal in mich gegangen. Hab nochmal an der Konfiguration herumgespielt...

Da muss noch was gehen. Aber ich weiß noch nicht wie.
Offenbar ist es so, dass module-rtp-recv von pulseaudio den Stream puffert, wenn ich auf ein anderes VT zu einem anderen User wechsle. Denn wenn ich zurück zum ursprünglichen User wechsle, spielt der Stream an genau der Stelle weiter, wo ich vorher weggesprungen bin. Stoppe ich dann mittels mpc stop den mpd läuft der Ton noch eine gute Weile weiter...
Ich vermute jetzt, dass es daran liegt, dass der Puffer von rtp-recv noch leergespielt wird.

Jetzt frage ich mich, ob es bei pulseaudio eine Möglichkeit gibt, den RTP-Stream-Empfang zu stoppen, wenn der User inaktiv wird (Stichwort loginctl... ) und wieder auf Empfang zu setzen, wenn der User wieder aktiv wird.
suspend-on-idle ist es ja nicht...

lg scientific

[smutbert]

Beim Videoabspielen kenne ich es beim VT-Switchen auch so, dass der versäumte Teil des Tones beim Zurückschalten nachgeholt zu werden scheint, aber irgenwie synchronisieren sich dann Ton und Bild wieder. Ist mir mit vlc schon ein paar Mal aufgefallen, aber da gings immer nur um relativ kurze Zeitspannen auf dem anderen VT - ich muss das noch einmal ausprobieren und aufpassen wie sich das genau verhält.

[scientific]

Wie es sich genau verhält, hab ich auch noch nicht rausgefunden.

Jetzt ist mir aber grad aufgefallen, dass danach auch der Ton verspätet einsetzt, wenn ich mpc stop und dann wieder mpc play abgesetzt habe. Scheint so, als ob der Stream dann überhaupt zeitversetzt wird.
Synchron wird es erst wieder, wenn ich killall pulseaudio als root ausführe.

Und soeben bemerke ich, dass atop für den Prozess gnome-shell zwischen 100% und 160% CPU-Last (2 Kerne!) anzeigt, sobald ich einen RTP-Stream von pulseaudio (mpd) zu pulseaudio (user) starte. Die CPU-Last geht auch nicht mehr zurück, wenn ich die Prozesse pulseaudio und mpd kille. Auch pasystray zu beenden ändert nix. Nur ein Restart der gnome-shell mit <Alt>+<F2> und r senkt die CPU-Last von gnome-shell...

Irgendwie funktioniert das alles nicht so, wie ich es gerne hätte...

[EDIT]
Ich korrigiere... pavucontrol hatte ich noch laufen. Das hat die hohe CPU-Last verursacht... :/

lg scientific