OpenMultiroom: Unterschied zwischen den Versionen

Aus FHEMWiki
(Weiterentwicklung des Artikels)
Zeile 76: Zeile 76:
== Aufbau anhand einer vollständigen Beispielkonfiguration ==
== 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.  
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 <em>/etc/systemd/system/pulseaudio.server</em> erreicht:
<source lang="bash">
[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
</source>
Weiterhin ist der Befehl
<source lang="bash">sudo systemctl enable pulseaudio</source>
einzugeben, um Pulseaudio beim Systemstart automatisch zu starten.
 
Ausgehend von der Standardkonfiguration werden nun in  <em>/etc/pulse/system.pa</em> die benötigten Module eingetragen
<source lang="bash">
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
</source>
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.
 





Version vom 25. Januar 2017, 15:10 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!
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:

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