OpenMultiroom: Unterschied zwischen den Versionen

Snapcast
Zweck / Funktion
	Steuern eines Snapcast-Servers
Allgemein
Typ	Gerätemodul
Details
Dokumentation	EN / DE
Support (Forum)	Multimedia
Modulname	96_Snapcast.pm
Ersteller	unimatrix
	Wichtig: sofern vorhanden, gilt im Zweifel immer die (englische) Beschreibung in der commandref!

OpenMultiroom
Zweck / Funktion
	Steuern der einzelnen Multiroom-Systemkomponenten
Allgemein
Typ	Gerätemodul
Details
Dokumentation	EN / DE
Support (Forum)	Multimedia
Modulname	98_OpenMultiroom.pm
Ersteller	unimatrix
	Wichtig: sofern vorhanden, gilt im Zweifel immer die (englische) Beschreibung in der commandref!

Version vom 25. Januar 2017, 18:22 Uhr

Schaubild des Zusammenspiels der einzelnen Komponenten eines Multiroomsystems mit den Backends MPD und Snapcast sowie der Nutzung von Text2Speech

Achtung: Dieser Wiki-Artikel und auch das beschriebene Modul sind noch in der Implemntierung und noch nicht verfügbar.

OpenMultiroom ist ein Steuerungsmodul sowie auch ein Gesamtkonzept zur Realisierung eines Multiroom-Audio-Systems unter Nutzung von ausschließlich frei verfügbarer Software und ohne Bezug auf die Hardware eines bestimmten Herstellers. Es ist so ausgelegt, dass es prinzipiell flexibel bezüglich der Auswahl der Backendsysteme ist. Zurzeit ist es für die Nutzung mit MPD bzw. Mopidy und Snapcast implementiert. Daher wird in diesem WIKI-Eintrag immer von diesen Systemen gesprochen. Einen grundsätzlichen Überblick über das Konzept bietet das Schaubild.

Grobe Übersicht des Funktionsumfangs der Gesamtlösung

Features

Integrierte Steuerung des Musikplayers über das MPD-Modul sowie des Multiroom-System Snapcast in einem einzigen Modul
Implementierung einer Schnittstelle gemäß DevelopmentGuidelinesAV als Basis für eine Visualisierung mit z.B. SmartVisu oder FHEM_Tablet_UI
Synchrones Playback auf z.B. Raspberry Pi oder Android-Geräten (Snapcast-Feature)
optionale Komprimierung der Soundübertragung als OGG oder FLAC (Snapcast-Feature)
Möglichkeit der Bedienung völlig ohne Display über eine Fernbedienung und entsprechender Text2Speech Rückmeldung, insbesondere
- Durschalten von Playlisten mit entsprechenden Channel - Tasten unter Nutzung von raumspezifischen Filtern
- Forward und Rewind mit definierbaren Sprungweiten (implementiert direkt im MPD-Modul)
- Direktanwahl von Playlisten, Tracks oder Trackpositionen durch Zifferneingabe und anschließende Funktionstaste
- Abfrage von Statusinformationen durch Funktionstasten und Text2Speech Rückmeldungen
- Mithören in anderen Räumen und Übernahme des Playerzustandes anderer Räume durch Nutzung von Funktionstasten
- Einschlaftimer per Zifferneingabe oder per vordefinierten Zeitabständen, hierbei wird auch die Restlaufzeit des aktuellen Tracks angeboten.
manuelles oder automatisches Speichern und Laden von Playlistbookmarks (implementiert direkt im MPD-Modul)
Möglichkeit der Festlegung von tageszeit- und tagestypabhängigen Lautstärkebegrenzungen bis auf 0% z.B. für Kinderzimmer
individuelles Verwalten von Playlisten für verschiedene Familienmitglieder
Nutzung des Audiosystems für systemunabhängige FHEM-Announcements. Ein entsprechendes Announcement-Modul ist in Planung. Dabei können mehrere Räume gleichzeitig oder auch getrennt angesprochen werden

Anwendungszweck und Kurzbeschreibung der Funktionsweise

Wie der Name des Systems vermuten lässt, ist die Lösung vor allem dann sinnvoll einzusetzen, wenn Audiodateien in mindestens 2 verschiedenen Räumen oder "Zonen" sowohl synchron als auch unabhängig abgespielt werden soll und wenn hierzu eine komfortable und integrierte Steuerung über FHEM verwendet werden soll. Mit Einschränkungen ist die Lösung auch dann sinnvoll, wenn es nur um das Abspielen in einem Raum geht. Hier kann dann z.B. die Steuerung über eine Fernbedienung mit Hilfe des OpenMultiroom-Moduls genutzt werden, die über eine reine Nutzung des MPD-Moduls hinausgeht.

Für die Nutzung ist nicht zwingend ein zentraler Server notwendig. Diese Rolle kann auch von einem der Clients übernommen werden, z.B. einem Pi. Zur einfacheren Darstellung wird in diesem Eintrag jedoch immer von der Nutzung eines Servers ausgegangen, der nicht gleichzeitig auch Client ist.

Das Abspielen von Audio funktioniert prinzipiell in 2 Stufen:

Nutzung von MPD oder einem MPD-kompatiblen Player zum direkten Abspielen von Sounddateien. Pro existierendem Raum gibt es mindestens eine Instanz von MPD. Hier wird davon ausgegangen, dass es genau eine Instanz pro Raum gibt. Jeder Raum hat also "seinen" MPD.
Nutzung von Snapcast zur Verteilung des von MPD abgespielten Sounds an den entsprechenden Raum. Snapcast übernimmt hierbei die zeitliche Synchronisation

Durch das Modul OpenMultiroom steuert der Nutzer sowohl MPD als auch Snapcast. Für jeden Raum wird eine Instanz des Moduls definiert.

verwendete komponenten

Folgende Komponenten kommen zum Einsatz:

Server:

MPD oder Mopidy oder ein anderer MPD-kompatibler Player. 1 Instanz pro Raum
Snapserver
mplayer (bei Nutzung von Text 2 Speech)
Optional Pulseaudio (im System-Mode) bei Nutzung von Text 2 Speech oder erweiterten Konfigurationen. Hierbei wird Pulseaudio zwischen MPD und Snapcast geschaltet.
Optional Anbindung an Subsonic oder Libresonic (hier zurzeit nicht beschrieben) zur Synchronisation von Playlisten uvm.
FHEM: Modul 98_OpenMultiroom.pm
FHEM: Modul 96_Snapcast.pm
FHEM: Modul 73_MPD.pm
FHEM: Optional Modul 98_Text2Speech.pm

Client:

Linux: Alsa oder Pulseaudio zur Soundwiedergabe
Linux: Snapclient
Android: Nur der Android Snapclient
Webbrowser zur Steuerung per Visualisierung
ggf. Infrarot oder Funkfernbedienung. In diesem Artikel wird das Beispiel anhand der Nutzung von X10-Funkfernbedienungen gezeigt, diese gibt es sehr günstig in der Bucht o.ä.
Vision: Nutzung von Tastern und Display am PI oder Nutzung eine Steuergerätes mit Tastern und Display auf Basis eines Arduino mit WLAN, z.B. im alten Gehäuse eines Küchenradios usw.

Aufbau anhand einer vollständigen Beispielkonfiguration

In diesem Artikel soll beispielhaft eine vollständige Konfiguration gezeigt werden. Jeder Nutzer muss diese Konfiguration an seine eigenen Bedürfnisse anpassen. Es seien folgende Komponenten vorhanden:

Server mit Ubuntu 16.04, hier befindet sich eine MP3-Sammlung
Kind1: Raspberry Pi Model 1 mit Raspbian
Kind2: BananaPi mit Ubuntu, an diesem Pi ist auch ein X10 Empfänger angeschlossen, da er zentral im Haus positioniert ist
Wohnzimmer: Raspberry Pi3 mit OSMC und KODI, wird primär zum Fernsehen verwendet
Küche: Raspberry Pi Model 1 mit Raspbian

Anmerkung: Es ist möglich, mehrere Räume mit nur einem physikalischen Client zu bedienen. Hierbei werden auf einem Client mehrere Instanzen des Snapclients laufen gelassen. Der physikalische Client hat dann z.B. mehrere USB Soundkarten, dessen Audioausgänge in verschiedene Räume verkabelt sind. Dies wird hier zurzeit nicht näher beschrieben.

Pulseaudio Konfiguration

Will man Pulseaudio verwenden, z.B. um Text2Speech Nachrichten in laufende Musik einzublenden, sollte dieses am besten zuerst konfiguriert werden. Pulseaudio muss hierzu im System-Mode laufen. Dies ist auf einem Headless-Server kein Problem. Bei Ubuntu 16.10 wird dies durch folgenden Inhalt in /etc/systemd/system/pulseaudio.server erreicht:

[Unit]
Description=PA
After=network.target sound.target

[Service]
ExecStart=/usr/bin/pulseaudio --system

# allow MPD to use real-time priority 50
LimitRTPRIO=50
LimitRTTIME=infinity

# disallow writing to /usr, /bin, /sbin, ...
ProtectSystem=yes

[Install]
WantedBy=multi-user.target

Weiterhin ist der Befehl

sudo systemctl enable pulseaudio

einzugeben, um Pulseaudio beim Systemstart automatisch zu starten.

Ausgehend von der Standardkonfiguration werden nun in /etc/pulse/system.pa die benötigten Module eingetragen

load-module module-pipe-sink file=/tmp/wohn.fifo   sink_name=wohn
load-module module-pipe-sink file=/tmp/kind1.fifo   sink_name=kind1
load-module module-pipe-sink file=/tmp/kind2.fifo  sink_name=kind2
load-module module-pipe-sink file=/tmp/kueche.fifo sink_name=kueche

load-module module-combine-sink slaves=kind1,kind2 sink_name=kinder
load-module module-combine-sink slaves=wohn,kueche sink_name=unten
load-module module-combine-sink slaves=wohn,kueche,kind1,kind2 sink_name=alle

Snapcast benötigt die Audioquelle in Form von FIFOs. Daher wird hier in den erstem 4 Zeilen je ein FIFO von Pulseaudio erzeugt. Der sink_name wird später bei der Konfiguration von MPD als Ausgang verwendet. In den 3 letzten Zeilen werden noch 3 weitere Sinks als Combine-Sinks erstellt. Diese erzeugen keine neuen FIFOs, sondern machen under entsprechenden Sink-Namen eine vorgegebene Kombination von Räumen nach außen hin verfügbar. Der Sink "alle" kann also genutzt werden, um Audio auf allen 4 FIFOs gleichzeitig abzuspielen (und somit später potentiall in allen Räumen gleichzeitig). Dies kann für Announcements sinnvoll sein. Die Nutzung dieser Combine-Sinks ist optional.

Snapcast Konfiguration

Snapcast muss entsprechend der Angaben auf der Webseite installiert werden. Auf dem Server muss logischerweise die Serverkomponente und auf den Clients die Clientkomponente installiert werden. Bei Android-Clients wird die auf der Webseite zur Verfügung gestellt APK installiert. Snapcast befindet sich selbst noch in fortlaufender Entwicklung. Die hier vorgestellte Lösung ist mit dieser Version kompatibel und getestet.

Die Konfiguration des Servers beschränkt sich auf die Definition der Streams in /etc/default/snapserver

START_SNAPSERVER=true
SNAPSERVER_OPTS="-d -s pipe:///tmp/kind1.fifo?name=kind1&mode=read -s pipe:///tmp/kind2.fifo?name=kind2&mode=read -s pipe:///tmp/wohn.fifo?name=wohn&mode=read -s pipe:///tmp/kueche.fifo?name=kueche&mode=read"

Hier werden die 4 Streams erstellt, diese entsprechen vom Dateinamen her der Pulseaudiokonfiguration. Der hier verwendete Name kann später in FHEM oder auch im Android-Client angezeigt werden. Die Option

mode=read

ist wichtig, weil Pulseaudio meckert, wenn es die FIFO-Dateien nicht selbst anlegen darf.

Auf der Clientseite sieht die Datei /etc/default/snapclient dann so aus:

START_SNAPCLIENT=true
SNAPCLIENT_OPTS="-d -s dmix:CARD=Aureon51MkII,DEV=0"

Den Server findet der Snapclient automatisch, er kann aber auch angegeben werden. Wie hier zu sehen kann ein spezielles Output-Device angegeben werden. Dies ist bei den PIs mit externer USB-Soundkarte meistens notwendig, da ansonsten der interne Sound genutzt würde. Eine Liste der verfügbaren Devices wird mit dem Aufruf von

snapclient -l

ausgegeben, hier muss dann das passende genommen werden. GGf. so lange ausprobieren, bis der Sound an der richtigen Stelle rauskommt.

In der hier betrachteten Konfiguration soll auf dem Wohnzimmer-PI ein Snapclient laufen, dieser wird aber normalerweise zum TV und Filme schauen mit KODI verwendet. Sowohl KODI als auch der Snapclient blockieren aber das ALSA-Device und funktionieren beide meistens entweder gar nicht oder nicht richtig zusammen, insbesondere dann nicht, wenn von KODI Mehrkanalsound oder sogar Passthrough ausgegeben wird. Die Entwicklung eines nativen Snapcast-Clients innerhalb von KODI wird gerade an verschiedenen Stellen diskutiert, z.B. hier. Bis dahin kann ein kleiner Workaround Abhilfe schaffen. Mit folgendem (nur rudimentär getesteten) Hack für den Snapcast-Client wird erreicht, dass der Client das ALSA-Device frei gibt, sobald er über den Server auf Mute gestellt wird. KODI selbst gibt das Device ebenfalls frei, wenn es im Zustand "Stop" ist. Bei dieser Lösung kann der Snapclient auf dem KODI-Rechner immer laufen gelassen werde. Es ist jedoch in der Verantwortung des Benutzers, den Client zu "muten". Vergisst er dies, wird ggf. die Wiedergabe in KODI nicht möglich sein.

Nach Abschluss der Snapcastkonfiguration und dem Starten von Server und den Clients empfiehlt es sich, die Android-App ebenfalls zu verwenden, da diese einen schnellen Überblick über den Zustand des Servers, der konfigurierten Streams und der Clients bietet.

Mopidy Konfiguration

In diesem Beispiel wird Mopidy als MPD-Ersatz verwendet, genau so gut kann aber auch direkt MPD verwendet werden. Die genauen Konfigurationsoptionen sind natürlich anders, und jeweils in entsprechenden Tutorials oder Dokumentationen beschrieben. Mopidy ist relativ umfangreich und modular aufgebaut, es bietet u.a. die Möglichkeit, neben lokal gespeicherten Dateien auch Dateien von verschiedenen, teilweise kommerziellen, Streamingdiensten abzuspielen. Die Detailkonfiguration all dieser Komponenten geht über diesen Artikel hinaus. Entscheidend hier ist die Konfiguration in einer Weise, so dass mehrere Mopidy-Instanzen gleichzeitig ausgeführt werden können und dann auf unterschiedlichen Ports zur Verfügung stehen.

Nach Installation von Mopidy findet sich die Konfiguration in der Datei /etc/mopidy/mopidy.cfg. Mopidy unterstützt hierarische Konfigurationen, es reicht also, den für jede Instanz spezifischen Teil aus dieser allgemeinen Konfiguration zu entfernen und in jeweils eigene Dateien zu verschieben. In diesem Beispiel sollen das die Dateien /etc/mopidy/kind1.conf bis /etc/mopidy/kueche.conf sein. Die folgenden Zeilen gehören jeweils in diese 4 Dateien und werden dort entsprechend angepasst. Hier das Beispiel für Kind2:

[logging]
config_file = /etc/mopidy/logging_kind2.conf
debug_file = /var/log/mopidy/mopidy-debug_kind2.log

[audio]
output = audioresample ! audioconvert ! audio/x-raw,rate=48000,channels=2,format=S16LE ! pulsesink  device=kind2

[mpd]
enabled = true
hostname = 0.0.0.0
port=6601

[http]
enabled = true
hostname =  0.0.0.0
port=6681
zeroconf = Musik Kind2

Im Audioteil wird der entsprechende Sink aus der Pulseaudiokonfiguration genommen. Beim MPD muss der Port für jede Instanz unterschiedlich sein, ebenso beim HTTP-Modul für die Weboberfläche der jeweiligen Instanz. Der Zerokonfname sollte auch eindeutig sein. Neben dieser Datei ist noch die dazu passende logging-Konfiguration anzulegen, hier also /etc/mopidy/logging_kind2.conf. Dazu wird die Standarddatei kopiert und darin nur der Name der Logdatei angepasst.

Um nun auch die entsprechende Anzahl Instanzen automatisch zu starten, sind die entsprechenden Startdateien anzulegen. Dazu kann die Datei /etc/systemd/system/mopidy.cfg z.B. in /etc/systemd/system/mopidy_kind1.cfg umbenannt werden und dann 3 mal mit den Endungen der anderen Instanzen kopiert werden. Der Inhalt ist dann wie folgt:

[Unit]
Description=Mopidy_kind1
After=network.target sound.target

[Service]
EnvironmentFile=/etc/default/mopidy
ExecStart=/usr/bin/mopidy --quiet --config /etc/mopidy/kind1.conf

# allow MPD to use real-time priority 50
LimitRTPRIO=50
LimitRTTIME=infinity

# disallow writing to /usr, /bin, /sbin, ...
ProtectSystem=yes

[Install]
WantedBy=multi-user.target

Abschließend sollten die 4 Instanzen durch den Aufruf von

systemctl enable mopidy_kind1

usw. aktiviert werden. Es empfiehlt sich nach dem Start von Mopidy die korrekte Funtkionsweise mit dem MPC-Client oder mit NCMPCPP auf der Konsole zu testen.

Hierbei sollte es dann bereits möglich sein, die Multiroom-Fähigkeiten von Snapcast mit Hilfe des Android-Clients von Snapcast zu testen und so auch festzustellen, dass die restliche Konfiguration von Snapcast und Pulseaudio korrekt sind.