- Wiedergabe des gleichen Audiosignals in mehreren Räumen (Hintergrundmusik)
- Die Fähigkeit, in jedem Raum ein eigenes Audiosignal wiederzugeben
- Möglichkeit der verteilten Wiedergabe von Benachrichtigungen (z. B. klingelt die Türklingel nicht in der Nähe der Tür bei voller Lautstärke, sondern bei geringer Lautstärke über alle oder über bestimmte Lautsprecher).
In diesem Artikel werde ich ein Beispiel für den Bau eines Mehrraumsystems in meiner eigenen Wohnung vorstellen. Die ursprüngliche Idee war, in allen Räumen eine Hintergrundmusik (den ausgewählten Radiosender) mit geringer Lautstärke zu erstellen, anstatt an einem Punkt, an dem die Lautstärke erhöht werden musste.
Grundlage für das Mehrraumsystem war die kostenlose Snapcast- Lösung . Der Serverteil wird auf dem Heimserver gestartet. Entweder Orange PI Zero-Minicomputer mit angeschlossenen aktiven Lautsprechern oder leistungsstärkere Rasberry PI mit einem installierten Kodi Media Player (Libreelec-Distributor) fungieren als Clients nach Raum.
Hauptmerkmale des fertigen Systems
- Spielen eines Internetradiosenders im Hintergrund
- Die Möglichkeit, Musik in einem Mehrraum (oder auf einem separat ausgewählten Client) mit Airplay, UPnP oder über einen Plex-Player abzuspielen. Es gibt Pläne, Bluetooth-Unterstützung hinzuzufügen, obwohl dies für mich nicht besonders relevant ist
- Abspielen beliebiger Inhalte von einem Computer über eine Webschnittstelle
- Änderung des aktuell wiedergegebenen Radiosenders manuell oder planmäßig
- Zuordnung zu jedem Client einer beliebigen Quelle
- Die Lautstärkeregelung ist für jedes Audiogerät individuell (dies funktioniert folgendermaßen: Die Steuerung des eigenen Audiosystems wird auf Maximum eingestellt, die Lautstärke jedes Snapclients wird bei Bedarf vom Server eingestellt (normalerweise auch auf Maximum eingestellt) und die Gesamtlautstärke wird von der Quelle aus eingestellt, von der aus die Wiedergabe erfolgt - dem Telefon , Computer-Player oder mpd)
Die Clients sind jetzt ohne Schnickschnack erledigt - es gibt Armbian, auf dem Shairport und Snapclient installiert sind, und es ist geplant, upmpdcli und Plexamp bereitzustellen, damit jeder Client als universeller Punkt fungiert, der den Ton unter Verwendung eines möglichen Protokolls wiedergibt. Das Hauptproblem, das dies immer noch verhindert, besteht darin, dass Linux die Freigabe eines ALSA-Audiogeräts für mehrere Programme nicht zulässt. Hier müssen Sie entweder andere ausschalten, während Sie Sound über einen Dienst abspielen, oder versuchen, Pulseaudio zu verwenden, was im Fall von Snapclient (Snapcast) nicht möglich ist funktioniert ausschließlich über ALSA, da es Verzögerungen minimiert und der Klang aller Quellen absolut synchron ist. Weitere Informationen finden Sie in der Snapcast-Dokumentation.
Die Serverseite ist als Microservices in Form mehrerer Docker-Container konzipiert, die zu einem Stapel zusammengefasst sind. Ursprünglich gab es Pläne, Container im Swarm-Cluster zu starten (ja, ich habe zwei Computer zu Hause, die zu einem Swarm-Cluster zusammengefasst sind, auf dem alle Dienste ausgeführt werden, die ich zu Hause benötige und nicht wirklich benötige), aber diese Idee musste aufgegeben und der Stack über Docker-Compose erstellt werden Die .yml-Datei wird auf einem der Computer ausgeführt. Die Zuverlässigkeit ist natürlich lahm, aber genug für zu Hause. Der Grund für die Unfähigkeit, im Cluster zu starten, besteht darin, dass der Snapcast-Server FIFO zum Empfangen des Audiostreams verwendet (eine typische Kette funktioniert so - der Sound wird mit mpd abgespielt, das Fifo ist das Ausgabegerät, von dem der Snapserver den Stream liest und an alle Clients überträgt). Aufgrund der Tatsache, dass der Cluster kein Volumen gemeinsam nutzen kann,Das Hosting eines Fifos zwischen mehreren Knoten (die Verwendung eines Fifos auf einem Host und die Weiterleitung über ein verteiltes Dateisystem funktioniert ebenfalls nicht. Obwohl dies möglicherweise über nfs möglich ist, habe ich es noch nicht ausprobiert). Es ist auch unmöglich, den Schwarmcluster zu zwingen, alle Container auf einem Knoten auszuführen. Die einzige Möglichkeit, allen Diensten Zugriff auf das FIFO zu gewähren, besteht darin, alles auf einem Knoten auszuführen (Sie können natürlich eine virtuelle Maschine oder einen riesigen Container erstellen, in dem alles über den Supervisor gestartet wird, aber ich habe beschlossen, dies nicht zu tun).Die einzige Möglichkeit, allen Diensten Zugriff auf das FIFO zu gewähren, besteht darin, alles auf einem Knoten auszuführen (Sie können natürlich eine virtuelle Maschine oder einen riesigen Container erstellen, in dem alles über den Supervisor gestartet wird, aber ich habe beschlossen, dies nicht zu tun).Die einzige Möglichkeit, allen Diensten Zugriff auf das FIFO zu gewähren, besteht darin, alles auf einem Knoten auszuführen (Sie können natürlich eine virtuelle Maschine oder einen riesigen Container erstellen, in dem alles über den Supervisor gestartet wird, aber ich habe beschlossen, dies nicht zu tun).
Stapelzusammensetzung
1) Snapserver. Snapcast-Server-Container. Es ist an den Ports 1704, 1705 und im Heimnetzwerk verfügbar. Aufrufe erfolgen über den DNS-Namen snapserver.local. Es weiß, wie es sich über Avahi ankündigt, aber wenn es in Avahi Docker arbeitet, werden Ankündigungen durch einen separaten Container geleitet (es ist nicht in diesem Stapel enthalten).
2) Snapcastr. Snapserver-Webdienst. Verfügbar an Port 5011 (verfügbar als snapcastr.local über lokalen Reverse-Proxy).
3) Snapchanger. Python-Skript, das Audioquellen analysiert und Clients auf die derzeit aktive Audioquelle mit der höchsten Priorität umschaltet. Zum Beispiel hat Internetradio die niedrigste Priorität und spielt immer. Wenn Sie Musik von einem Telefon über Airplay abspielen, wird auf diesen Stream umgeschaltet. Wenn in diesem Moment ein Signal von einem Smart Home eingeht, wird auf diesen umgeschaltet. Wenn ein Stream gestoppt wird, wechselt er zurück zu den aktiven Streams mit der höchsten Priorität. Für jeden Client können Sie Ihre Liste der Threads und Prioritäten für sie angeben.
4) Snapcron. Ein Container mit Cron, der zu einem bestimmten Zeitpunkt Skripte ausführen kann, z. B. um die Lautstärke auf Clients zu ändern (schalten Sie die Musik im Schlafzimmer nachts vollständig aus).
5) mpd. mpd Instanz zum Abspielen von Internetradio. Über ein nicht standardmäßiges Port 36602 an das Heimnetzwerk weitergeleitet.
6) Funk. Pyhthon-Skripte, die sicherstellen, dass das Radio immer abgespielt wird (es gibt Fälle, in denen die Verbindung unterbrochen wird oder die Verbindung vorhanden zu sein scheint, der Ton jedoch nicht abgespielt wird) sowie das Umschalten von Radiosendern und Lautstärke je nach Tageszeit.
7-8) mpd.fm und pifi - Web Shells zum Abspielen von Radiosendern. Zwei Stücke des gleichen Typs für Experimente.
9) Mopidie. Eine weitere Shell (auch bekannt als separater MPD-Server) zum Abspielen von Musik. Es fungiert als separater MPD-Server und reagiert auf den Standard-MPD-Port - 6600. Kann zum Hören von Musik verwendet werden. Es verwendet einen eigenen Stream und arbeitet unabhängig von mpd für Radiosender.
10-12) shairport-sync, upmpdcli, plexamp - Container mit entsprechenden Clients. Jeder der Container verwendet eine eigene Instanz von mpd und schreibt in sein eigenes FIFO. Jeder Client hat also seinen eigenen unabhängigen Stream.
Somit unterstützt der Stapel jetzt:
- Mehrere unabhängige Tonquellen mit beliebiger Auswahl - Standard, uPnP, Mopidy, Plexamp, AirPlay und Internetradio.
- Verwalten des Snapcast-Servers selbst mit Snapcastr.
- Eine Reihe von Skripten, um einen zuverlässigen und unterbrechungsfreien Hintergrundradio-Sound zu gewährleisten.
- Steuern der Radiowiedergabe mit pi-fi oder mpd.fm (außerdem habe ich die Steuerung dieser mpd-Instanz mit dem in meiner Heimautomation verwendeten Node-Red konfiguriert).
Repository-Link