OpenMultiroom: Unterschied zwischen den Versionen
(Snapcast und Mopdy hinzugefügt) |
|||
Zeile 123: | Zeile 123: | ||
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 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 === | |||
[https://github.com/badaix/snapcast 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 [https://github.com/badaix/snapcast/tree/98be8a58d945f84af50e40ebcf8a774592dd6e7b dieser Version] kompatibel und getestet. | |||
Die Konfiguration des Servers beschränkt sich auf die Definition der Streams in <em>/etc/default/snapserver</em> | |||
<source lang="bash"> | |||
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" | |||
</source> | |||
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 <pre>mode=read</pre> ist wichtig, weil Pulseaudio meckert, wenn es die FIFO-Dateien nicht selbst anlegen darf. | |||
Auf der Clientseite sieht die Datei <em>/etc/default/snapclient</em> dann so aus: | |||
<source lang="bash"> | |||
START_SNAPCLIENT=true | |||
SNAPCLIENT_OPTS="-d -s dmix:CARD=Aureon51MkII,DEV=0" | |||
</source> | |||
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 <pre>snapclient -l</pre> 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. [https://github.com/badaix/snapcast/issues/155 hier]. Bis dahin kann ein kleiner Workaround Abhilfe schaffen. Mit folgendem (nur rudimentär getesteten) [https://github.com/unimatrix27/snapcast/commit/88e42a2ecc8b44223701e18abb63af04b673b67b 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 <em>/etc/mopidy/mopidy.cfg</em>. 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 <em>/etc/mopidy/kind1.conf</em> bis <em>/etc/mopidy/kueche.conf</em> sein. Die folgenden Zeilen gehören jeweils in diese 4 Dateien und werden dort entsprechend angepasst. Hier das Beispiel für Kind2: | |||
<source lang="bash"> | |||
[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 | |||
</source> | |||
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 <em>/etc/mopidy/logging_kind2.conf</em>. 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 <em>/etc/systemd/system/mopidy.cfg</em> z.B. in <em>/etc/systemd/system/mopidy_kind1.cfg</em> umbenannt werden und dann 3 mal mit den Endungen der anderen Instanzen kopiert werden. Der Inhalt ist dann wie folgt: | |||
<source lang="bash"> | |||
[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 | |||
</source> | |||
Abschließend sollten die 4 Instanzen durch den Aufruf von <pre>systemctl enable mopidy_kind1</pre> usw. aktiviert werden. Es empfiehlt sich nach dem Start von Mopidy die korrekte Funtkionsweise mit dem [https://www.musicpd.org/clients/mpc/ MPC]-Client oder mit [http://rybczak.net/ncmpcpp/ 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. | |||
[[Category:Examples]] | [[Category:Examples]] | ||
[[Category:HOWTOS]] | [[Category:HOWTOS]] | ||
[[Category:Unterhaltungselektronik]] | [[Category:Unterhaltungselektronik]] |
Version vom 25. Januar 2017, 17:22 Uhr
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! |
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! |
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.