DIY Multiroom Projekt

[drdownload]

Spannend mein FHEM weiß noch nix von dem attr im Dropdown, muss wohl mal ein Update machen - aber super das es was hilft

[unimatrix]

das Modul ist ja noch nicht mal im SVN. Musst man sich manuell aus dem GIT holen.

[drdownload]

Ah, da hat mich die Erinnerung der Installationsgenese verlassen

Gesendet von meinem MI 5 mit Tapatalk

[unimatrix]

Mir ist jetzt relativ klar wie meine Endarchitektur ist. Folgende Module werden zusammenspielen

- 1 Snapcast Server Modul
- je Client ein Snapcast Client Modul
- je Client ein MPD Modul - entsprechend je Client eine Mopidy Instanz auf dem Server
- je Client ein Modul "MultiroomAudioController", das kommt noch
- je Client ein Modul Text To Speech Modul, welches ich für meine Zwecke erweitern werde
- je Client ein Modul NumberHelper, das kommt noch, das wird für Zahleneingabe mit Zifferntasten verwendet

Das MultiroomAudioController Modul ist das einzige, mit dem der User interagieren muss. Die Schnittstelle laesst sich direkt zu den Tasten von gängigen Fernbedienungen mappen, das soll so flexibel wie möglich sein und entsprechend konfigurierbar. Das Modul spricht mit dem Snapcast Client Modul sowie mit dem MPD Modul, die ihm jeweils zuzuordnen sind.

Das Modul nutzt außerdem optional ein zugeordnetes Text to Speech Modul, um bei einem Headless-System (wo man also nur die Boxen und eine Fernbedienung hat) entsprechend Audiofeedback geben zu können. Das TTS wird so erweitert, dass sich auch voraufgenommene MP3-Files hinterlegen lassen, auch für die Ausgabe von beliebig großen Zahlen. Es soll die Ausgabe auch auf einem Remote Pulseaudio Server möglich sein. Dies macht bei Clients sinn, wo Snapcast auf PA abspielt, so könnte man dann das Audiofeedback einmixen. Bei z.B. KODI geht das dann nicht. Ich prüfe dann noch inwieweit DMIX helfen kann. Für Android kann es sinnvoll sein, über eine Integration mit AMAD nachzudenken. Zumindest anschauen werde ich vll die Idee, das TTS MP3 über Mopidy abzuspielen und so lange die laufende Ausgabe zu unterbrechen. Schade dass Snapcast nicht mixen kann.  Oder vll kann Pulseaudio in ein FIFO schreiben? Dann ginge es noch anders.

Das Modul Numberhelper wird benutzt, um mehrere Ziffern die auf einer Fernbedienung eingegeben werden, zu mehrstelligen Zahlen zusammenzubauen. Kommt noch.

Meine genaueren Ideen dazu pflege ich in einer TXT Datei auf dem GIT.
PS: Neue Snapcast Version seit heute online mit Clientmodulen und ID-Readings.

[drdownload]

pulseaudio kann auch pipe-sinks habe aber noch nicht das zusammenspiel ausprobieren können weil aus irgendeinem grund mir die option auf dem musik server kein fifo file anlegt, genau die gleiche zeile am notebook aber schon...

update: ah, die pipe-sink legt er mir nur nicht im daemon/system mode an ... pffff (pulseaudio und ich werden keine freunde )

update2: systemd und ich auch nicht - mit der privatetmp=yes option ist es klar, dass ich kein fifo file sehe

[drdownload]

So, ich glaube jetzt läuft es so halbwegs rund. (traue ich mich zu sagen ohne es zu verschreien - hoffentlich) bisherige Problem wie extreme Verzögerungen inkl. Lockup von Mopidy beim Stoppen/Wechseln/(v.a. beim Streamen von Radio) sind jetzt weg.

Komponenten: Mopidy, Pulseaudio, Snapscast
Alle als Systemd units gesteuert (mopidy für die verschienen zonen parametrisiert)


Mopidy:
Config geteilt in Core (für allg. Pfade, Spotify User etc.) und Zonen-Config für Ports + Output (hier könnte man auch unterschiedliche Musik-Libraries pro Zone machen (zB für Kinder)
Output ist: pulsesink server=127.0.0.1 device=1 (Anm. Ob/wie ich die Sink mit Sinkname ansprechen kann weiß ich noch nicht, aber device index geht)

Pulseaudio
load-module module-native-protocol-tcp auth-anonymous=1
load-module module-pipe-sink file=/tmp/pulsefifo_1 sink_name=pulsefifo_1 (etc.)

Snapcast
-s pipe:///tmp/pulsefifo_1?name=Wohnzimmer&sampleformat=48000:16:2&codec=ogg&mode=read \

[drdownload]

Für Android kann es sinnvoll sein, über eine Integration mit AMAD nachzudenken.

Interessant wäre hier v.a. die App neu starten zu können (zB weil ich den Snapcast-Server neu starten musste)

[unimatrix]

Leider weiss das Modul ja erstmal nicht, dass der Server neu gestartet wurde, allerdings sollte dieses Android Problem ja hoffentlich in Snapcast selbst gefixt werden.

[drdownload]

Ich denke das müsste ja nicht automatisch passieren, es ginge nur darum nicht eine Runde durch das Haus drehen zu müssen um alle Android clients neu zu connecten. Ich hätte mir da einfach einen Dummy mit doif gemacht um ein "resync snapcast clients" zu machen

Starten kann amad2 ja, beenden gibt es theoretisch bei Automagic auch insofern

Auf wienerisch "es warat wegen dem waf"

Gesendet von meinem MI 5 mit Tapatalk

[unimatrix]

Verstanden, schaue ich mir aber vll später an. Ich mache jetzt den Controller weiter. Da habe ich jetzt folgende Logik implementiert:

Ein Controller je Snapcast Client. Mit dem Controller Modul kann man direkt denjenigen MPD/Mopidy steuern, auf dessen Stream man gerade hört. Ich glaube so ist es auch für die Visualisierung am besten.

[Wzut]

MPD mal angeschaut. Da wird immer wieder die Verbindung zum MPD Server in einem eigenen Prozess aufgebaut. Mir ist noch nicht klar wieso. Ich unterstelle mal dass da ein guter Grund hinterstand.

Der Grund ist recht einfach : Der Autor wusste es vor drei Jahren nicht besser als er sein  erstes fhem Modul zusammen kopiert hat
Tipp: Fragen dieser Art sollte man im MPD Fred stellen, dort könnte dir vllt auch geholfen werden. Der MPD Fred ist i.d.R. auch der einzige Fred den ich hier im Abschnitt Multimedia lese, der heutige Ausflug hierher war reiner Zufall.

[unimatrix]

Hallo,
danke fuer das Feedback. Ich hätte mich auch im MPD Thread noch gemeldet, wollte mir aber das Modul erst noch genauer anschauen. Ich habe mir schon gedacht dass das historische Gründe hat bzw. das war mir dann klar, als ich den gesamten MPD Thread gelesen habe. Meine Probleme kamen aber woanders her, so dass ich da jetzt auch gar nicht den großen Nachteil sehe.

Ich muss erstmal meine eigenen Module fertigstellen

[drdownload]

Noch als Idee:

Im Player (MPD oder multiroomaudio) eine Liste mit Benutzern hinterlegen die den Player "locken" oder "claimen" können, dass man weiß, dass der gerade in Benutzung ist.

Bzw. ein Reset to default Values.

PS. "was machst du da eigentlich, dass es immer woanders kurz geräusche macht" hat sich gewandelt zu "du hast doch was mit der musik gemacht, ich beschwer mich aber nicht" - nachdem in der früh automatische die lieblingsplaylist im badezimmer gelaufen ist

[unimatrix]

Das hab ich jetzt noch nicht komplett verstanden.

Wer ist ein Benutzer wodurch kennzeichnet der sich?
"den Player locken" - was genau locken und was soll dann nicht mehr gehen?

Kannst du das etwas genauer beschreiben was du meinst?

[drdownload]

Die Story wäre:

User fängt im Büro einen Podcast zu hören, geht ins Bad duschen und will den Podcast weiterhören während User 2 ins Büro geht und dort seine eigene Musik hören will.

Eher als Hilfe für die Leute die nicht auf den Playstate des Players schauen