DIY Multiroom Projekt

[FranzB94]

Hi unimatrix!

TTS gibts ja offenbar schon was, was aber nur online geht....

Die Erstellung der Dateien erfolgt online, die Daten werden aber zur wiederholten Verwendung lokal gespeichert.

DLNA kenne ich mich überhaupt nicht mit aus und finde ich für meine Ansprüche uninteressant. Den Code vom MPD Module habe ich mir schon sehr genau angeschaut. Da kann man einfahc ein paar neue Befehle einbauen ohne dass es die Kompatibilität zur jetzigen Version stört.

So kann man sich irren. Meiner Meinung nach basiert das MPD-Modul auf den DLNA/UPnP-Grundlagen! Nicht zuletzt melden sich die Geräte mit ihrer uuid und der Name wird nach dem Schema DLNA_... vergeben. 

Ich finde für den Einstieg den, leider schon älteren Artikel http://www.heise.de/netze/artikel/Netzwerke-mit-UPnP-einrichten-und-steuern-221520.html interessant und anregend.

Im fhem-Wiki sind auch sicher sehr interessante Guidelines hinterlegt http://www.fhemwiki.de/wiki/DevelopmentGuidelinesAV. Vielleicht mags du da auch mal reinschauen.
Bin auf deine Lösung sehr gespannt! 

[drdownload]

Wo ich sicher später Hilfe gebrauchen kann ist bei der Visualisierung. Ich bin vollkommen unkreativ. Da könnte man sich ein total cooles Widget für SmartVISU machen. Die bestehenden Widgets bieten dazu nicht alle notwendigen Funktionen.

da würde ich mich gerne einarbeiten nachdem smartvisu bei mir jetzt für alles kommt

Ausgangspunkt wäre für mich bei Smartvisu das Sonos Widget https://github.com/ddtlabs/smartvisu-widgets/tree/master/sonos

[unimatrix]

bin dran musste mich allerdings erstmal mit vielen Grundlagen der Modulentwicklung rumschlagen, habe allerdings viel Hilfe dazu hier im Forum bekommen und es geht voran.

Das MPD Modul hab ich relativ genau gelesen (Also den Sourcecode) das macht gar nix mit DLNA. Vll ne alte Version? K.a.

Die AV Guidelines hab ich gesehen. Das ist dann fuer das Modulinterface wichtig. Im Moment bin ich tief im Backend und die Steuerung der Pulseaudiosachen. Das muss erstmal sauber laufen. Da gibts so einige Kniffe weil pulseaudio nicht gerade dafuer entwickelt wurde, automatisiert benutzt zu werden. Habe immerhin Antwort von dem PA-Entwickler. Der will mir noch was wg. Android schicken aber k.a. ob das nutzbar sein wird.

[unimatrix]

wie alles geht es langsam voran aber es geht.

Der Code ist jetzt mal auf Github
https://github.com/unimatrix27/fhemmodules

Man kann einen PAServer Define anlegen mit einer IP-Adresse - dieser Host, das kann localhost sein, muss mit dem Tool pactl erreichbar sein und pulseaudio muss laufen

Man kann beliebig viele PAClient Defines anlegen. Ebenfalls mit IP, ebenfalls muss auf denen pulseaudio laufen und sie muessen vom FHEM Rechner aus per pactl erreichbar sein. Diese finden den Server dann (hoffentlich) automatisch als IODev. Sie registrieren sich am Server und der Server stellt dann die pulseaudio tunnel automatisch her und setzt entsprechende Readings.

mit set <PAClient> desired-master <ein-anderer-client> kann man sagen, dass ein Client bei einem anderen Client mithoeren will, also dann Multiroom. Der Server stellt dann automatisch einen Combine-Sink her. mit set desired-master none wird das rueckgaengig gemacht.

Also naechstes kommen noch diverse Pruefungen und dann noch die automatische Umleitung der sink-inputs. Auf dem PAServer sollte ein Null-Sink angelegt sein. In der doku werde ich dann beschreiben wie alles genau konfiguriert sein muss. Dann kommt die Anbindung an MPD.

bis in Kuerze

[unimatrix]

Habe nun eine ganz gut funktionierende Version auf dem Github. Ich habe mal um einen Wikiaccount gebeten damit ich die Konfiguration etc dokumentieren kann.

[Hellspawn]

Hallo,

klingt ziemlich spannend. Tolle Arbeit.

Gruß
Carsten

[unimatrix]

Projekt geht weiter, die letzte Woche konnte ich aber nix machen. Ich rechne mit einem Update in den nächsten Tagen, spätestens nach dem Wochenende

[LeoSum]

Hattest du dir vorher Snapcast mal angesehen?

https://github.com/badaix/snapcast

Wenn ja, was hat dagegen gesprochen darauf aufzusetzen?

[kleinerDrache]

Hey cooles Projekt muss ich mir mal genauer anschauen.
Bisher nutze ich Runeaudio auf pi's in den Räumen. Gesteuert jeweils über das MPD und das DLNA Modul (wegen tts) . geht ganz gut jeder pi hat seine eigenen playlists die können aber auch auf einer Freigabe abgelegt werden . ist halt etwas unübersichtlich.

Wenn ich Zeit finde werd ich aber mal deine Sachen ausprobieren. Danke für die ganze Arbeit.

[drdownload]

Hi,

unter https://home-assistant.io/blog/2016/02/18/multi-room-audio-with-snapcast/ habe ich gefunden, wie man mehrere Mopidy Instanzen gleichzeitig laufen lassen kann.

edit: habe auch binnen Minuten spotify zum Laufen gebracht, durch das MPD frontend von Mopidy damit sicher eine Komponenten-Alternative

[drdownload]

jetzt weiß ich wieder warum ich damals das Projekt gelassen habe pulseaudio gerade mit system daemon ist eine zickige diva ...

1x bekomme ich zugriff auf pacmd, dann wieder nicht, dann kann pulseuaudio wieder nicht starten als user daemon, argl.

[drdownload]

@unimatrix, ein paar Fragen:

Man braucht nur noch PAServer.pm und PAClient.pm aber nicht mehr das Skript aus dem Git?

Wie kann ich denn definieren was für eine sink genommen werden soll?

[drdownload]

Hi, ich habe jetzt auch mal weitergebastelt

Ich habe jetzt testweise am Server (in der Folge Source genannt) eine mopidy-Instanz laufen, die direkt im Output auf eine Pulseaudio-Sink auf einem RPi (Target) geht. (in Smartvisu habe ich die MusicBox Webif eingebunden zum Steuern).

Das ist mal mein simples Setup, dass ich schnell gebraucht habe um mein spinnertes Android-Küchenradio zu ersetzen.

Der weitere Plan wäre:
Auf der Source weitere parallele Mopidy-Instanzen, die jedoch nicht direkt im Output auf Netzwerk-Sinks schicken sondern lokal eine Null-Sink + eine Loopback-Sink die dann auf die Netzwerk-Sink am Target geht. Damit könnte ich mal eine 1:1 Bindung zwischen Zone-Player und Zone-Sound herstellen.

Das MPD-Modul wäre mMn nach noch immer das Beste für eine Standard-Einbindung in FHEM, nur den Output-Switch unterstütz Mopidy nicht, da müsste man rein mit Pulse-Audio arbeiten, was ich aber logisch finde: zone1.musik.wohnzimmer ist zB mein Standard-Mopidy im Wohnzimmer. Zusätzlich gibt es zone2.musik.kueche und zone3.musik.terrasse. Die werden selten(nie) einzeln Musik auswählen sondern
a) "mitgenommen" > ich gehe ins Bad und höre eine Reportage/Podcast weiter (fieses Szenario)
b) dazugeschaltet.

zone3.musik.kinderzimmer, zone4.musik.buero, zone5.musik.badezimmer, zone6.musik.schlafzimmer und zone7.musik.dachterrasse wären wohl auch meistens 1:1.

(Ob ich über ALSA das Device-Numbering zusammenbringe, dass ich mehrere baugleiche USB-Soundkarten anspreche wird sich noch zeigen.)

Update: es ist keine Loopback-Sink sondern eine Combined geworden, aber das reicht mal für heute als POC. --- Pulseaudio bleibt aber ein Biest.

[unimatrix]

bin wieder da. eure Alternativen schaue ich mir gerne noch an.

Welches Script aus dem GIT? da sind doch nur die beiden FHEM Module?

Das mit dem Pulseaudio als System geht schon ganz gut finde ich. Es kommt immer drauf an was die Ausgangslage ist. Auf kleinen PIs die im Grunde headless sind und für sonst nix genutzt werden macht ja eig. nur der Systemmode Sinn. Auf einem Headless Server sowieso.

pacmd funktioniert nicht mit System Mode, aber pactl. Damit das geht muss man nur das Modul mit anonymous auth laden und im Zweifel an 0.0.0.0 binden. Natürlich ist es dann komplett offen, bei mir ist aber mein Netz anders gesichert und jedem der im Netz ist wird vertraut.

Ich werde jetzt im nächsten Schritt eure Alternativen anschauen aber dann wohl erstmal meine Integration vorantreiben. mopidy werde ich dabei berücksichtigen, trotz der noch vorhandenen Nachteile.

[unimatrix]

nachdem ich mir nun Snapcast angeschaut habe, was ich leider vorher gar nicht kannte, überlege ich, ob es noch sinnvoll ist, die PA Geschichte weiter zu machen. Snapcast scheint mir moderner zu sein. Schade eig, das hätte ich mal eher sehen müssen