DIY Multiroom Projekt

[drdownload]

Bei snapcast gibt es mmn nach 2 Probleme:
Ein Client kann nur eine snapcast zone bedienen
Wir haben kein fhem Modul dafür (Python Library gibt es)

weitere Dinge auf die ich bei meinen Versuchen mit snapcast drauf gekommen bin:
Android 4.x Client ist Buggy im Themenkomplex sampling rate. Ich habe es nicht geschafft mit mopidy transcoding etc eine durchgehende Pipeline zu bekommen.

[unimatrix]

ok danke fuer die Hinweise.

Es gibt ja eine Steuerung für HomeAssistant insofern da das ganze ja offenbar über JSON RPC gesteuert werden kann, wäre dann auch ein FHEM Modul vll. immer noch einfacher als mein PA Kram.

ok Android Client habe ich noch nicht probiert. Schaue ich mir an. Kommt in meinem Setup aber wohl nur sekundär vor.

[unimatrix]

hmm was meinst du mit "ein client kann nur eine Snapcast Zone bedienen" ?

Wenn ich den Server mit mehreren Streams anlege, kann ich die Clients zischen den Streams ja "hin und herschieben" .. meinst du dass ein Client auf mehreren Streams gleichzeitig lauschen kann?

[drdownload]

Hi, die Steuerung für HA (das ist auch in Python geschrieben) ist einfach ein wrapper um die existierende Python Steuerungs-Library.

Ich habe (dadurch, dass ich nur dünne Rigipswände habe und einen zentralen Gang von dem aus ich in alle Zimmer komme (kleine Wohnung) derzeit den Plan mit nur 1 RPi auszukommen an dem dann 4 USB-Soundkarten hängen. (+ 1 mit 3 im Wohnzimmer)

Über PA geht das, bei Snapcast kann aber auf einer Hardware nur ein Client laufen weil die ID des Clients die Mac-Adresse ist.

[unimatrix]

die Lösung dazu lautet VLAN auf dem PI so dass der mehrere MAC Adressen hat. Hab ich noch nie gemacht aber sollte eig. gehen.

http://www.foxplex.com/sites/virtuelle-netzwerkschnittstellen-unter-linux-mit-macvlan/

[drdownload]

Nur kann man dem Snapcast-Client nicht seine ID mitgeben - welche MAC nimmt er dann ...

[unimatrix]

zusammen mit Docker sollte das gehen. Ich probiere jezt mal ob ich das auf die Schnelle testen kann.

[unimatrix]

also Docker ist da schon Kanonen auf Spatzten es geht noch viel einfacher, und zwar mit Network Namespaces.

Ich habe bei mir ein frisches Raspbian Image draufgespielt und dann:

1.
http://unix.stackexchange.com/questions/210982/bind-unix-program-to-specific-network-interface

2. http://unix.stackexchange.com/questions/210982/bind-unix-program-to-specific-network-interface

Nun kann man jede Software innerhalb eines virtuellen Network Namespace laufen lassen. Es sieht dann nur das IF, was in diesem Namespace ist.

In /etc/networking/interfaces kann man fuer jedes virtuelle Interface einen eigenen Hostnamen eintragen, der dann in der Snapcast App auch so zu sehen ist. Ein Beispiel siehe unten.

Code Auswählen Erweitern


auto veth0
iface veth0 inet dhcp
   hostname pi_zone1
   pre-up ip link add name veth0 address 02:4e:a6:27:01:07 link eth0 type macvlan
   post-down ip link delete dev veth0

auto veth1
iface veth1 inet dhcp
   hostname pi_zone2
   pre-up ip link add name veth1 address 02:4e:a6:27:01:08 link eth0 type macvlan
   post-down ip link delete dev veth1



und dann folgendes bei jeden Start ausfuehren:

Code Auswählen Erweitern

ip netns add snap1ns
ip link set veth0 netns snap1ns
ip netns exec snap1ns ip link set veth0 up
ip netns exec snap1ns dhclient veth0

ip netns add snap2ns
ip link set veth1 netns snap2ns
ip netns exec snap2ns ip link set veth1 up
ip netns exec snap2ns dhclient veth1

ip netns exec snap1ns snapclient -h x.x.x.x -s <audiodevice zone 1> -d
ip netns exec snap1ns snapclient -h x.x.x.x -s <audiodevice zone 2> -d

[unimatrix]

das mit dem Hostnamen hat so doch nicht geklappt. Ich habe es jetzt mit dem zusaetzlichen Schritt über Unshare:

Code Auswählen Erweitern

unshare -u
sudo echo newhost > /proc/sys/kernel/hostname


und dann den Client starten, siehe oben

[drdownload]

Wow, ich dachte ich bin bei Linux Networking nicht so schlecht, aber das ist mir mit verträumten Morgenaugen noch zu hoch. Muss es später mal probieren.

Snapcast ist schon cool, weil genau dafür gedacht.

Effektiv sehe ich es mittlerweile als 2 Komponenten (in 4 Modulen) die wir hier haben.

1) Die Player für die einzelnen Zonen (in meinem Test-Szenario erstmal die 2 Mopidy-Instanzen die hier nebeneinander laufen)

2) Die Audio-Pipeline (fifo + snapcast bzw. pulseaudio). Für mich wären das zwei gleichberechtigte Möglichkeiten die man wie folgt splitten könnte:
Multiroom-Steuerung die Zonen-Merge etc. verwaltet. (das dann entweder PA oder SC als IO hat)
Pulseaudio Helper modul (pactl basierend)
Snapcast Helper modul (über die API)

Warum ich gerade nicht schaffe snapcast am rpi (arch based) zu bauen ist wieder was anderes

[unimatrix]

Ich habs auch gestern zum ersten mal gesehen, das mit den Namespaces, das ist aber praktisch sehr leicht und so eine Art VM-Light. Genauso lassen sich natürlich auch mehrere Snapcast Server auf jeweils eigenen virtuellen IPs betreiben. So könnte man z.B. eine Art Broadcast-Server haben, der einen Stream hat, wo immer alle Clients drin sind, um Durchsagen usw. machen zu können.

https://en.wikipedia.org/wiki/Linux_namespaces

Ja was du meinst macht als Architektur schon Sinn, also ein Multiroom Modul das unabhängig vom Backend ist. Im Detail allerdings schon etwas tricky. Bei PA sind es ja mehrere Module (1 Instanz für Server und eine Instanz für jeden Client), bei Snapcast sehe ich im Moment nur ein Servermodul für den SC-Server, da der ja über alle Möglichkeiten verfügt. Die Clients müssen einfach nur den SC-Client starten, dazu braucht man eig. kein FHEM Modul. Das Snapcast-Helper-Modul dürfte am leichtesten sein. Ich habe mir gestern die JSON-Steuerung angesehen, die ist ja sehr trivial und bietet alle Möglichkeiten, denn die wird ja auch von der python Software und von der Android App genutzt. Außerdem hat sie Event-Callbacks. Das ist sehr gut, das vermeidet das Polling, was ich für PA bauen musste. Somit kann man die Verbindung über JSON RPC als IO nutzen, so wie jedes andere IO in FHEM. Ich versuche mich mal daran.

Mit Mopidy kämpfe ich noch. Ich habe ca. 80.000 MP3s in meiner normalen Sammlung. Das Webif (mopify) hängt ständig. K.a. obs daran liegt.

Was mir an SC richtig gut gefällt ist, dass es sich offenbar den Zustand von Clients merkt, auch wenn diese Offline gehen, und auch wenn der Server selbst offline geht. Auch der Code von Snapcast ist zumindest für mich erfassbar, anders als bei PA wo ich nur Bahnhof verstehe. Da könnte man wenns notwendig ist sogar mal selbst ran...zumal das wohl überwiegend ein 1-Mann-Projekt ist bisher.

[drdownload]

Ja, da bin ich voll bei dir was die Vorteile von snapcast betrifft. Nett ist auch ogg als Option wenn man mit flac Bandbreitenprobleme hat.

Unabhängig davon ob man pulseaudio überhaupt realisiert würde ich Trennung in extra Module sinnvoll finden. Wer weiß was für eine tolle Lösung noch neu daherkommt.

Der snapcast Server kann ja auch so schon unterschiedliche Zonen um eine announcement zone zu haben.

Ich habe mir das Thema announcement noch aufgehoben weil ich finde die müssten sofort kommen können und nicht erst wenn ich den Verstärker eingeschaltet habe und die zone Ansprechen kann.

Anderes Ding: ich bin mir nicht auf die Auswirkungen auf die WiFi Bandbreite sicher wenn ich 7 Zonen mit flac broadcaste selbst wenn keine device im wifi ist die den Stream bekommen sollte. Früher war das ja ein Problem aber ich habe mich lange nicht mehr beschäftigt.

Anderes spannendes Thema in das snapcast Modul inaktive Zonen einzubauen die man erst mit zB Verstärker einschalten aktivieren muss.

Gesendet von meinem MI 5 mit Tapatalk

[unimatrix]

Das mit unterschiedlichen Zonen ist mir so noch nicht klar.

Ich weiß wie ich auf einem Snapcastserver beliebig viele Streams / FIFOs parallel laufen lasse. Aber ein Client kann nur auf einem Stream sein, nicht auf mehr als einem. Oder?

Bei mir ist fast alles über LAN. Ich habe mal meine beiden Tables und ein Android Phone eingebunden und da läuft noch alles synchron. Es gibt aber ab und zu kleine Pausen. Resync funktioniert offenbar über Silence. Bei PA wird da eher langsamer oder schneller gespielt, weil das natürlicher klingt. Bei den LAN Clients habe ich das noch nicht beobachtet. Bei WLAN wird man wohl mit kleinen Nachteilen leben müssen.

Multicast wird wohl bisher nicht unterstützt, das wäre sicher keine triviale Erweiterung.

7 mal gesendet wird ja nur, wenn die Clients auch connected sind. Es wird allerdings auch dann gesendet, wenn sie auf Mute sind. Es gibt schon ein Issue im Git mit dem Wunsch, das Senden beim Muting auch zu stoppen.

[drdownload]

Ah, falsch im Hinterkopf, dachte das wäre jetzt schon multi cast, dann müllt es nix zu

1 Client kann nur 1 zone wiedergeben

Gesendet von meinem MI 5 mit Tapatalk

[drdownload]

Was ich als Option auch noch nicht gefunden habe ist beim snapclient eine bestimmte audiodevuce zu verwenden

Gesendet von meinem MI 5 mit Tapatalk