Hallo,
Update 26.01.2017: Die Ideen und Diskussionen aus diesem Thread sind inzwischen in den 2 neuen Modulen OpenMultiroom und Snapcast aufgegangen. Dieser Thread ist als Archiv zu verstehen und somit jetzt geschlossen. Feedback usw. sollte in den Threads der beiden Module stattfinden:
Snapcast: https://forum.fhem.de/index.php/topic,62389.0.html (https://forum.fhem.de/index.php/topic,62389.0.html)
OpenMultiroom: https://forum.fhem.de/index.php/topic,65785.0.html
-----
nach langer Marktrecherche bin ich für mich zu dem Ergebnis gekommen, dass keine sinnvolle Multiroom Audiolösung auf dem Markt existiert, die meinen Ansprüchen gerecht wird. Daher habe ich ein DIY Projekt angefangen und auch schon in der 1. Phase umgesetzt. Für die weitere Entwicklung suche ich Anregungen und ggf. auch Hilfe in der Umsetzung.
So sieht mein Setup aus:
- ich habe einen zentralen Server mit Ubuntu. Es spielt keine Rolle, ob dies "nur" ein PI oder ein echter Server ist. Dieser beinhaltet auch die Musiksammlung (wobei es egal ist wo die ist)
- ich möchte Musik in mehreren Räumen im Haus wiedergeben. Das sind meistens MP3s die ich auf dem Server habe. Aber auch Streams z.B. Radiostreams.
- Ich habe mehrere Familienmitgliedern die ihre eigenen Playlists verwalten möchten
- Die Steuerung erfolgt primär nicht über eine App, Tables, Webif, etc. sondern über X10 Fernbedienungen. Diese gibts für sehr wenig Geld z.B. bei Pollin und mit einem X10 Empfänger habe ich in meinem Haus (was über 3 Etagen geht) überall Empfang. Der X10 empfänger ist einfacherweise am Server per USB angeschlossen.
- Die Räume sind teilweise angrenzend, daher muss ein synchrones Playback der gleichen Quelle in mehreren Räumen gleichzeitig möglich sein, bzw. ist es auch schon. Es muss aber genau so gut möglich sein, jeden Raum individuell zu bespielen, und auch das ist schon so.
Im Detail funktioniert es zur Zeit wie folgt:
In jedem Raum steht ein Rechner mit Linux. Das ist meistens ein Pi, ich habe aber auch noch eine alte Dockstar im Einsatz. Im Wohnzimmer steht ein HTPC mit VDR der ebenfalls dazu zählt.
Die Verteilung der Audiosignale läuft über pulseaudio. Auf dem Server und allen Clients läuft pulseaudio im system-Modus. Für jeden Client wird auf dem Server ein tunnel-sink angelegt. Im Falle von einer Wiedergabe in mehreren Räumen gleichzeitig wird dazu noch ein combined-Sink angelegt.
Die eigentliche Wiedergabe läuft über MPD. Hier möchte ich später auf die neue Python version von MPD umsteigen, da diese z.B. auch Spotify und vieles mehr unterstützt. Für jeden konfigurierten Client läuft auf dem Server eine MPD Instanz.
Die Musiksammlung insgesamt wird bei mir mit Subsonic verwaltet. Subsonic hat eine vernünftige Weboberfläche zum Verwalten von Playlisten und es gibt gute Apps für Android und für Iphone. Unabhängig von diesem Projekt nutze ich auf Android die App DSub um Musik z.B. im Auto zu hören. Meine Kinder können sich mit ihrem eigenen Subsonic Account per Webinterface eigene Playlisten machen oder die gemeinsamen Playlisten nutzen.
Mit einem regelmäßig laufenden kleinen Perl Script werden aus den Subsonic Playlisten MPD Playlisten erzeugt. Dabei werden die persönlichen Accounts berücksichtigt (und die Playlisten den passenden Räumen, z.B. Kinderzimmer zugeordnet) Die einzelnen MPD Instanzen kennen also jeweils ein unterschiedliches Subset an Playlisten. Das habe ich so realisiert, dass ich die Playlisten bei der Konvertierung mit einem Prefix benenne.
Die einzelnen Clients sind nicht alle always on (einige schon). Hier nutze ich fhem, um diese per Funksteckdose einzuschalten und auszuschalten (per shutdown und verzögertem Ausschalten der Steckdose). Bei den Always On Clients habe ich zumindest die Lautsprecher, die ja eine eigene Stromversorgung haben per fhem steckdose schaltbar gemacht, damit diese nur laufen wenn Musik gespielt wird.
Ich habe eine Perlapplikation entwickelt, die als Dienst auf dem Linuxserver läuft und im wesentlichen folgende Aufgaben übernimmt:
- Er öffnet einen Socket, auf dem die Signale von irexec dann eingehen. Dies kann z.B. sein ,,play wohnzimmer". Im Wohnzimmer hat also jemand auf play gedrückt.
- Es sendet je nach empfangenden kommande auch Befehle an FHEM um z.B. einen Client einzuschalten. Wie im beispiel oben, im Wohnzimmer drückt jemand Play auf der Fernbedienung. Falls dieser Client noch nicht an ist, wird er jetzt eingeschaltet und das play Command in eine Queue gestellt mit einem Timeout.
- Es scannt die ganze Zeit das Netz ab und schaut, welche Clients online sind und welche nicht. Dazu wird im ersten Schritt Ping genutzt und im zweiten Schritt der Pulseaudio-Client ,,pactl"
- Es legt bei Erscheinen von neuen Clients im Netz (als Resultat davon, dass die jemand eingeschaltet hat) einen entsprechenden Pulseaudio-Sink auf dem Server an. Es weist dann diese neuen Sink als output der passenden MPD Instanz zu. Der Client wird somit als online markiert.
- Er führt alle weiteren Kommandos aus, die auf den Fernbedienungen gedrückt werden. Play startet dann den MPD Playback, entsprechend gibt es alle üblichen Kommandos für Pause, Next, Prev, Fast Forward usw. (Fast Forward ist hier so realisiert, dass einen festen Prozentsatz der Länge des MP3s gesprungen wird)
Über spezielle Kommandos (bei mir auf den Fernbedienungen auf den Farbtasten) kann sich ein Raum an einen bereits laufenden Raum ,,anhängen". Wiederholtes Drücken auf den ,,Attach" Knopf hängt den Client zyklisch an die anderen zurzeit eingeschalteten Räume an. Ist kein anderer eingeschaltet, passiert nichts. Der Dienst legt dazu einen Pulseaudio combind Sink an, pausiert die MPD Wiedergabe, schaltet den MPD Output auf den neuen Sink, und startet sie wieder (das passiert so schnell, dass es nicht hörbar ist). Der dann angehängte Raum läuft vollkommen audiosynchron zum bereits laufenden. Per weiterem Farbkommando ,,control" kann ein anderer Raum in diesem Kontext dann auch gesteuert werden. Man kann also im 1. Kinderzimmer entscheiden, dass man jetzt auch das hören will, was im 2. Kinderzimmer läut, und dann auch direkt das 2. Kinderzimmer steuern. Dies kann ggf. durch Rechte eingeschränkt werden.
Auf den X10 Ferbedienungen gibt neben Knöpfen für Next und Prev noch ein paar für Channel Up und Down. Dieses habe ich für den Playlistwechsel verwendet. Hier kann man durch die Playlisten durchschalten.
Die Lautstärketasten bewirken über den Dienst, dass die Pulseaudio Client Lautstärke per pactl auf den Clients tatsächlich verändert wird. Da die numerischen Werte 0-100% bei den an den Pis angeschlossenen USB-Soundkarten alles andere als linear sind, ist in der Config für jeden Client eine Linearisierungs-Lookup Tabelle hinterlegt, die 10 Lautstärkestufen feste %-Werte zuweist.
Da Pulseaudio keine vernünftige APi hat (soweit ich weiss), rufe ich jeweils das pactl Tool auf und parse die Ausgabe mit regulären Ausdrücken. Das ist teilweise doof, da auch die Lokalisierung greift.
Für die Kommandos Next, PlaylistNext, VolUp, und FastForward kann durch die vorherige Eingabe von 1-n Ziffern ein Ziel vorgegeben werden. So führt die Eingabe von 1,5,Next dazu, dass MPD auf Track nummer 15 springt. Der Server merkt sich hierbei die Ziffern mit einem gewissen Timeout.
Da die ganze Bedienung ohne Display erfolgt, habe ich eine audiomäßige Rückmeldung implementiert. Hierbei nutze ich Signaltöne und von meinen Kindern aufgesprochene Sprachschnipsel. Beispiel Zifferneingabe: Die erkannte Zahl wird bei jeder Ziffer ausgegeben. Die Ziffernfolge 1,4,7 folgt nacheinander zu der Sprachausgabe: 1, 14, 147. Zahlen bis 60 liegen als MP3 vor, Zahlen darüber werden aus entsprechenden MP3s zusammengeschnitten wenn sie gebraucht werden.
Über die Konfiguration wird pro Raum festgelegt ein Zeitprofil mit Maximallautstärke vorgegeben. Lautstärke 0 in diesem Kontext heisst, dass der Raum nicht angeht. Hierdurch wird realisiert, dass sich die Musik bzw. Hörspiele in den Kinerzimmern zur Einschlafzeit zunächst von der Lautstärke begrenzt und zu festen Zeiten ganz abschaltet. Die Tagesprofile sind hier in die Kategorien Standard, beforefree, free und beforeschool unterteilt. Beforefree ist normalerweise Freitags (also ein Schultag, aber am nächsten Tag ist frei). Beforeschool wäre ein Sonn- oder Feiertag (es ist frei, aber am nächsten morgen muss man früh aufstehen). Ferien werden berücksichtigt (aus FHEM ausgelesen per Google Kalender)
Die Zeitprofile habe ich genau so umgesetzt wie die Heizzeiten bei Homematic, da ich dafür schon sowieso einen Parser entwickelt hatte.
Beim Umschalten zwischen Playlisten speichere ich den Playstate von MPD ab, so dass man beim zurückschalten an die gleiche Position kommt wo man sie verlassen hat. Gleiches beim Ausschalten usw.
Soviel zum Ist-Stand.
Letztlich möchte ich ein FHEM Modul über das alles abläuft, und auch der Zustand in entsprechenden Readings von den Räumen sichtbar ist. Ich nehme an man hat ein Client Modul und ein Server Modul und dann mehrere Instanzen vom Client Modul. Im nächsten Schritt kommt die Smartvisu Anbindung. Dazu müssen dann Widgets verändert und erstellt werden um z.B. die Funktion ,,Anhängen an einen anderen Raum" grafisch irgendwie abzubilden.
Um dahin zu kommen muss ich das bestehende wohl ziemlich umschreiben. Das ganze läuft, ist aber schwierig zu debuggen, da ich unter anderem Perl::Async nutze wegen der ganzen blocking Sachen (pactl, ping, mpd etc das sind alles blocking calls)
Bisher habe ich nur eine rudimentäre Übersicht über den Zustand des Systems per printf und Data::Dumper Ausgaben. Ein Webinterface fehlt völlig.
Da meine Kinder größer werden soll die Steuerung dann auch über Smartvisu per Smartphone möglich sein.
Am liebsten hätte ich eine sauberere Pulseaudio Anbindung aber hier scheine ich ein Exot zu sein, der sich eine normale API wünscht die man z.B. von perl ansprechen kann.
Für den Spezialfall dass ich den einen Raum auch als HTPC nutze, auf dem VDR zum Fernsehen und KODI für Filme etc. läuft brauche ich noch eine bessere Lösung. Die neueste VDR Version funktioniert mit Pulseaudio. Ich würde mich gerne auch an den Fernsehton in anderen Räumen anhängen können (Szenario: Bundesliga, etc). Ich möchte auch den VDR und Kodi mehr über FHEM steuern. Das ist dann so eine Art Entweder-Oder Sache. Auf dem HTPC kann entweder Musik laufen, der VDR fürs Fernsehen, oder KODI. Ich brauche noch ein FHEM Modul dass das irgendwie regelt, beim Umschalten auf KODI muss auch pulseaudio deaktiviert werden da damit kein DTS-HD Passthrough möglich ist.
Dann stehen noch andere KLenigkeiten auf der Liste. Pausieren bei eigehenden Anrufen (client- und telefonnummernabhängig) Signalisierung von anderen Dingen auf eingeschalteten Clients (Türklingel, Wäsche fertig, etc.) Am liebsten hätte ich auch die Möglichkeit für spontane Durchsagen ,,Kommt alle zum Essen" oder so. (Ja unser Haus ist etwas groß)
Ich sollte noch sagen, dass ich alle Geräte per Gigabit LAN angebunden habe. Die Datenrate ist klein, aber bei WLAN kann es Latenzprobleme geben. Dazu habe ich wenig Erfahrungswerte, da ich WLAN nur für Smartphones und Tablets einsetze.
Ich schreibe das hier alles, weil ich mir Kommentare und Anregungen erwünsche bzw. erhoffe. Ggf. hat der ein oder andere schon mal etwas ähnliches angefangen. Ich tue mich schwer mit einer sauberen Programmierung, mein Code ist sehr undurchsichtig. Speziell das Handling von asynchronen und blocking Sachen bereitet mir Schwierigkeiten.
Als erstes wäre es interessant zu erfahren, ob mein Setup schon so speziell ist, dass kein anderer damit was anfangen kann. Offenbar sind so Sachen wie Squeezeboxen sehr verbreitet. Sie bieten aber meiner Ansicht nach viele Nachteile. Die bei mir verwendete Hardware ist günstiger als alle fertigen Lösungen. Eine Squeezebox wäre erst dann schön, wenn man sie komplett mit einer Custom Firmware ausstatten könnte.
Hi,
genau das wäre auch mein Plan gewesen, den ich schon schon einem Jahr hin- und her schiebe und immer wieder Teile realisiere um sie dann wieder zu killen.
Btw. wenn mit Python MPD auf mopidy anspielst, das kann weder sinnvoll mehrere Instanzen noch multiple Outputs.
Bin noch im Büro und daher nur drübergeflogen.
ok find ich gut dass ich nicht der einzige bin der sich sowas krankes ausdenkt. ja mopidy meine ich habe es mir aber noch nicht genau genug angesehen. hmm na gut möglicherweise dann doch nicht.
Meinen Code kommentiere ich gerade rudimentär und stelle ihn dann mal ein. Also heute noch.
Bei meinem Codereview gerade hab ich festgestellt dass ich pactl noch blocking aufrufe. Das läuft normal schnell aber wenn ein Host nicht erreichbar ist dann hängt es 2 Sekunden. Das ist schlecht. Ich habe keine Ahnung wie man das ganze korrekt implementiert, um nichts blockendes zu haben und dann mit Callbacks oder so zu arbeiten. In meinem SCript habe ich ja Die Async Lib aber das macht ja keinen Sinn wenn es ein FHEM Modul ist. Vll muss es ja auch keins werden sondern es bleibt ein eigener Dienst den man dann mit FHEM steuern könnte.
hier mal die aktuelle Implementierung. Ich habe meine persoenliche Config komplett drin. Aber das sollte unkritisch sein. So bekommt ihr eine Vorstellung von meinem Haus und davon wann meine Kinder ins Bett muessen ;)
Den Code habe ich heute erstmalig rudimentaer kommentiert. Bei einigen Sachen weiss ich nicht mehr wie das eig. funktioniert. Das ganze ist bei mir aber seit 18 Monaten in fast taeglicher Benutzung.
https://github.com/unimatrix27/mpd_multiroom (https://github.com/unimatrix27/mpd_multiroom)
Nachdem nach meiner Meinung auch Pulseaudio-Sinks die einzig sinnvolle MR-Steuerung ermöglichen habe ich schon überlegt ob ich mit web.py oder dgl. ein simples Webservice baue um die Sinks ordentlich steuern zu können (ähnlich http://mateusz.viste.fr/attic/pawebgui/ ). Haupthindernis bei meiner Umsetzung war bis jetzt, dass sich in immer mehr Räumen Android-Devices sammeln (Mediaplayer und Tablets) und ich die gerne integrieren würde, aber da noch nicht weitergekommen bin.
Habe immer wieder Mini-Setups mit 2 RPis und einem Openwrt Mini_Router mit Pulseaudio die ich von einem Arch-Desktop aus ansteuere, aber so richtig integriert bin ich noch nicht ;) Zu unentschlossen was die Zieltechnologie betrifft (lande auch immer wieder bei LMS/Squeezeserver) Fernsehen ist bei mir nicht VDR sondern tvheadend und die Mediacenter haben alle Kodi als Frontend. Zusätzlich läuft emby als Mediaserver
Akuteller Plan wäre: im oberen Stockwerk wo die Schlafzimmer sind am Server 4 USB-Soundkarten anzuhängen und direkt in die Zimmer zu fahren vom Gang aus.
Future Projekte: Ein Radio mit Tablet zur Steuerung für meine Kinder bauen, Die CD-Sammlung mit RFID-Tags ausstatten um sie ohne Einlegen abzuspielen ;)
Danke fuer das Feedback. Inwieweit hindern dich die Android Devices? Oder soll auf denen auch Sound ausgegeben werden? Als Steuerung will ich ja eh auf Smartvisu mit einem eigenen Widget, das sollte dann sowieso primär auf Android benutzt werden.
Es hilft mir zu wissen was andere für HW-Konfigurationen und Vorstellungen haben damit ich meinen Code einem Refacturing unterziehen kann so dass das dann generalistischer anwendbar ist. Das mit den USB Soundkarten klingt irgendwie...."nicht richtig" :) ...zumal man ja da auch das handling managen muss von wegen ein Stream oder verschiedene Streams
Was meinst du mit dem Future Project "radio mit tablet zur Steuerung" ? RFID ist lustig. Ich habe meinen Kindern mal "Magic Codes" gegeben um auf neue Hoerspiele zugreifen zu koennen...tja da schaut die Familie doof wenn es nur Codes zu Weihnachten gibt. ;)
Nachdem ich geizig bin würde ich natürlich gerne die Android-Devices gleich als Sinks verwenden ;)
Meine Zonen (und was vorhanden ist)
Küche (Android-Tablet)
Wohnzimmer (Android Mediaplayer am AV-Verstärker)
Terrasse (USB-Audio an OpenWRT (hat aber noch nie wirklich funktioniert) am AV-Verstärker, 2. Kanal)
Gästezimmer (Android Mediaplayer an Soundbar)
Kinderzimmer soll für Kinder bedienbares Radio bekommen
Badezimmer sollte auch Musik bekommen (event. nur über Handy steuern)
Schlafzimmer same (FireTV-Stick mit Kodi am Fernseher)
Stream-Management
Wie gesagt, ich spiele schon länger rum, aber hatte noch nie ein sinnvolles Ergebnis, daher muss nicht alles richtig sein ;)
Am Server für jede Zone eine MPD-Instanz mit einem Output und dann über pacmd ggf die sinks mergen oder trennen.
Projekte ;)
Einen Ghettoblaster für die Kinder bauen mit eingebautem Tablet
RFID Reader zum Abspielen von Playlisten (http://www.rg42.org/wiki/rfid/mprfid)
mir ist keine Loesung bekannt um Pulseaudio auf Android zu "leiten". Hast du da was probiert? Man kann sicher RTP Streams abspielen und das Abspielen koennte man ueber FHEM / AMAD2 automatisieren. Ich hatte allerdings schonmal eine Lösung mit RPT und Multicast in meiner Vorversion und das hat total viel Bandbreite gebraucht, die Tunnel Sinks brauchen offenbar viel weniger. Das wird dann mit WLAN vll. schwierig. Außerdem wäre dann kein Sync sauber möglich.
Offenbar hat mal Arun Raghaven (einer der PA Entwickler) PA auf Android portiert aber das ist schon lange her, ich habe ihn mal angeschrieben...
Zählt für dich eine X10 Funkfernbedienung ohne Display als Radio für Kinder bedienbar? Also meine Kinder machen das und kommen gut klar (wenn sie einen Knopf drücken kommt ja Feedback per Audio, ist also interaktiv)
Ich werde jetzt mal ein FHEM Modul basteln was die Sinks dynamisch anlegt. Das sollte ich eigentlich hinbekommen. Bzw 2 Module. Ein Modul PA_Server und ein Modul PA_Client. Einem CLient wird per attr konfiguriert zu welchem Server er gehoert. Der Server ueberwacht dass PA ueberhaupt erstmal laeuft und schaut fuer jeden Client, ob er online ist, und wenn ja, legt er fuer jeden einen Sink an auf dem Server. Dann stelle ich mir das so vor dass man per "set <client> combine [<client2>]" einen Client an einen 2. Client anflanschen kann. Dadurch wird der Sink fuer den Client 2 ersetzt durch einen combine Sink der auf die tunnel-sinks von Client 1 und Client 2 geht.
Die MPD Instanzen sollen je nur noch einen Output haben und zwar jeweils einen eigenen Null-Sink. Dann kann man den Rest per move-sink-input machen. Dadurch kommt es zu keinem unerwarteten Verhalten wenn Clients einfach so offline gehen usw.
ich hoffe dieser Ansatz macht irgendwie Sinn...
Was du unter Stream Management schreibst geht mit meinem Code schon jetzt alles.
Hi,
für Android hätte ich folgende App als Kandidaten noch gefunden aber selbst noch nicht getestet https://play.google.com/store/apps/details?id=com.kaytat.simpleprotocolplayer
danke schaue ich mir dann sicher mal an.
Hi, ich bin jetzt mal früher zuhause und endlich dazugekommen genau durchzulesen + auf github das perl skript anzusehen, erstmal: Gratulation, das ist eine wirklich tolle Lösung die du da gebaut hast und dass du dir auch noch die Arbeit antust es zu refactoren um es tiefer in FHEM einzubauen.
Ich bin leider überhaupt nicht so der Perlmensch (Python, C# und PHP sind eher meins) - ich brauche immer 2h bis selbst 20 Zeilen myutils laufen ;)
Meine Kinder sind erst 4 und 7 und bis jetzt ist ihre Musikauswahl CDs und Hörbücher von ihrem iPod, daher mein Gedanke das über ein Tablet zu steuern für die 2, mit dem iPod gehen sie schon super um.
Meine Bedienung für die "Normalverbraucher" ist auf Basis von Smartvisu.
Nachdem noch einige RPi1 rumliegen wäre es sicher auch möglich überall (zB mit 2 Soundkarten beim AV-Verstärker) einen richtigen Linux-Client zu haben (meine Geräte sind normalerweise Arch basieren außer dem Server (OMV/Debian)
Danke für das Feedback. Ja man muss aufpassen dass die Kinder nicht erwachsen sind, bis man die Software fertig entwickelt hat ;) (meine sind jetzt 9 und 12)
Grund für die FHEM Portierung ist ja die Hoffnung, das modularer machen zu können. Ein MPD Modul gibts schon. Das müsste ich leicht erweitern. Für die Visualisierung etc. könnte man viel vorhandenes Nutzen und es wäre eine integrierte Lösung. Ich hatte das damals in so einer Marathon Aktion innerhalb eines Wochenendes gebastelt und dann später nur noch kleine Bugs beseitigt.
Die erste Rohfassung meines FHEM Modules läuft schonmal. Dauert aber noch da alles non-blocking sein muss.
Die Lösung mit meiner Fernbedienung hat den Vorteil, dass die Kinder im Bett liegen und durch reines Ertasten das Ding steuern können. Hab da relativ viel Zeit investiert um die ganzen Pings, Blings, Zong, Dadaa, Dudeldidu usw Geräusche zu konfigurieren. Aber die Kinder hatten viel Spaß beim erstellen der MP3s. Denn da es ja keine Trackanzeige gibt habe ich so Sachen wie 150 Folgen Benjamin Blümchen ebenfalls modifiziert. Denn die fangen ja alle mit der gleichen Titelmusik an. Ich habe alle diese Hörspiel MP3s mit einer Titelansage versehen die am Anfang eingespielt wird. Alles von Kindern aufgesprochen.
Hi unimatrix!
Zitat von: unimatrix am 18 Oktober 2016, 19:38:56
...Grund für die FHEM Portierung ist ja die Hoffnung, das modularer machen zu können. Ein MPD Modul gibts schon. Das müsste ich leicht erweitern. Für die Visualisierung etc. könnte man viel vorhandenes Nutzen und es wäre eine integrierte Lösung...
Erfahrungsgemäß kommt ja bei solchen "Prosa-Threads", wie es dieser bisher ist, nicht viel raus. Aber ich will mich auch mit dem Multiroom-Thema beschäftigen und deshalb lese ich hier mit.
Da du nun das MPD-Modul erwähnst, wird das Thema aus meiner Sicht interessant. Für die unterschiedlichste Multimedia-Hardware gibt es ja bereits fhem-Module. Den Sinn des MPD-Moduls hatte ich darin gesehen, diese Hardware zu steuern. Das Modul findet zwar unterschiedlichste Renderer, aber die Steuerung der Geräte funktioniert nur teilweise. Offenbar werden die XML-Dateien der Geräte nicht oder nur teilweise berücksichtigt?
Leider verstehe ich von der Programmierung noch viel zu wenig, bin aber sehr an diesem Thema interessiert und würde mich gern beteiligen.
Da du ja eine viel größere praktische Erfahrung mit dem Theme hast, wünsche ich dir viel erfolg. Hoffentlich kann ich praktisch auch estwas zur Realisierung beitragen.
Franz
@Franz,
ich glaube du verwechselst da das MPD Modul mit DLNA/UPNP wo man immer die XMLs braucht.
Außerdem hat unimatrix schon eine lauffähige Version die er freundlicherweise für alle in FHEM Module umgestalten will.
@unimatrix
Fällt dir auch eine Lösung für Text-To-Speak ein?
TTS gibts ja offenbar schon was, was aber nur online geht. Ansonsten mp3 generieren und abspielen. Wollte ich noch mit einbauen weil ja nicht jeder voraufgenommene Dinge haben wird.
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.
Habe seit gestern Abend erste lauffähige FHEM Module aber die meiste Arbeit steckt noch in dem ganzen Handling von Ausnahmebedingungen z.B. wenn Geräte einfach abgeschaltet werden usw.
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.
Hi unimatrix!
Zitat von: unimatrix am 19 Oktober 2016, 10:36:50
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.
ZitatDLNA 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 (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 (http://www.fhemwiki.de/wiki/DevelopmentGuidelinesAV). Vielleicht mags du da auch mal reinschauen.
Bin auf deine Lösung sehr gespannt!
Zitat von: unimatrix am 19 Oktober 2016, 10:36:50
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
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.
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
Habe nun eine ganz gut funktionierende Version auf dem Github. Ich habe mal um einen Wikiaccount gebeten damit ich die Konfiguration etc dokumentieren kann.
Hallo,
klingt ziemlich spannend. Tolle Arbeit.
Gruß
Carsten
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
Hattest du dir vorher Snapcast mal angesehen?
https://github.com/badaix/snapcast
Wenn ja, was hat dagegen gesprochen darauf aufzusetzen?
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.
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
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.
@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?
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.
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.
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 :)
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.
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.
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?
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.
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/ (http://www.foxplex.com/sites/virtuelle-netzwerkschnittstellen-unter-linux-mit-macvlan/)
Nur kann man dem Snapcast-Client nicht seine ID mitgeben :( - welche MAC nimmt er dann ...
zusammen mit Docker sollte das gehen. Ich probiere jezt mal ob ich das auf die Schnelle testen kann.
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 (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 (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.
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:
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
das mit dem Hostnamen hat so doch nicht geklappt. Ich habe es jetzt mit dem zusaetzlichen Schritt über Unshare:
unshare -u
sudo echo newhost > /proc/sys/kernel/hostname
und dann den Client starten, siehe oben
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 ;)
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 (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.
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
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.
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
Was ich als Option auch noch nicht gefunden habe ist beim snapclient eine bestimmte audiodevuce zu verwenden
Gesendet von meinem MI 5 mit Tapatalk
mit snapclient -l kann man sich die Audiodevices anzeigen lassen und mit snapcard -s dann eins davon festlegen. Das packt man dann einfach in die /etc/default/snapclient
Das brauchst du ja auch für dein "Mehrere Snapcast Clients auf einem PI" - Szenario, aber das hab ich hier auch mal mit 2 USB Soundkarten ausprobiert und das geht einwandfrei.
Ah super, danke, bin den ganzen Tag unterwegs und am Handy hab ich die Info nicht gefunden.
Gesendet von meinem MI 5 mit Tapatalk
mehrere Mopidy Instanzen geht auch problemlos. Man kann offenbar die config Files in einer Hierarchie laden. So kann man ein globales File lassen, und für die Instanzen dann ein 1.conf, 2.conf usw. anlegen und dort nur die abweichenden Werte eintragen, also die Portnummern für den MPD Service usw.
Readings vom SC Modul dann so? Macht das Sinn? Die Anzahl der Clients ist ja dynamisch da kann man ja nur durchnummerieren.
Der Name kann übrigens 2 Quellen haben. Entweder es ist für die MAC einer fest konfiguriert: Das passiert dann, wenn man den Client z.B. in der Android App umbenennt bzw. dann eben auch per FHEM. Wenn man das nicht macht, bleibt das Feld leer und es wird der Hostname des Clients angezeigt.
Man kann aber Namen mehrfach vergeben. Für das "set <scmodul> <client> muted false" bleibt also fast nichts anderes uebrig, als die IP oder die MAC zu nehmen. Oder man macht es flexibel. Wird ein Name verwendet, dann nimmt man eben den ersten gefundenen. Wer dann so "doof" ist, gleiche Namen zu vergeben kann ihn so nicht ansprechen bzw. muss die MAC verwenden. Oder?
Kennst du dich mit Smartvisu aus? Wie muss die Schnittstelle (also Readings und set xxx) aufgebaut sein, das man das da gut integrieren kann?
https://snag.gy/zBFCR7.jpg
Zitat von: unimatrix am 10 Dezember 2016, 16:28:38
mehrere Mopidy Instanzen geht auch problemlos. Man kann offenbar die config Files in einer Hierarchie laden. So kann man ein globales File lassen, und für die Instanzen dann ein 1.conf, 2.conf usw. anlegen und dort nur die abweichenden Werte eintragen, also die Portnummern für den MPD Service usw.
genau und die lädt man dann über --config file1.conf:file2.conf
Ich habe bis jetzt nicht viel Musik nicht in mopidy versucht. (bin auch noch beim Aufräumen - daher vielleicht 1000 MP3s und Spotify in mopidy)
Ich werde mir Mal das sonos Modul in Smart visu ansehen, va wie man dir readings auseinander dividiert von mehreren devices.
Bei Sets ist es praktisch keine noargs zu haben. Dann muss man deutlich weniger konfigurieren beim zusammenhängen
Gesendet von meinem MI 5 mit Tapatalk
ok super, danke. Ich habe es jetzt erstmal 1:1 umgesetzt, das Interface kann man leicht anpassen. Das Modul ist im GIT. Freue mich ueber Tests.
https://github.com/unimatrix27/fhemmodules/blob/master/96_Snapcast.pm
Bedienung:
fhem> define snap Snapcast localhost 1705
fhem> set snap help
Unknown argument help, choose one of update muted latency volume stream name
fhem> set snap volume kueche 20
fhem> set snap volume 02:50:09:41:3c:29 50
fhem> set snap name kueche neuername
fhem> set snap name neuername kueche
Am besten dabei die Android auf haben dann sieht man live alle Auswirkungen der Sets. Die Readings updaten sich ebenfalls, wenn man per Android was ändert usw.
Als nächstes ein wenig Doku und dann Zusatzfunktionen z.B.
fhem> set snap kueche stream next
fhem> set snap kueche stream default
fhem> set snap masterreset
fhem> set snap scene 1
fhem> set snap scene 2
fhem> attr snap constraintDummy kindOfDay
fhem> attr snap volConstraint kueche beforeSchool 06:30 0 08:00 40 09:00 57 18:00 120 19:00 70 20:00 65 20:30 57 21:20 40 21:30 30 24:00 0
fhem> attr snap volConstraint kueche beforeFree 06:30 0 08:00 40 20:00 120 21:00 65 21:30 57 22:00 40 22:30 30 24:00 0
wow, das ging ja flott :)
ich muss jetzt erstmal wieder ein paar snapcast clients hochziehen ;) was mir aufgefallen ist: wenn ich die pipeline versuche über 44100 samplingrate zu machen (mit ogg als format) motzen zwar alle android clients, dass es nicht die native samplingrate ist, aber ein android 6 und ein android 4.2 client spielen es ruckelfrei ab. (beide über wifi). wahrscheinlich ist in der app etwas hardcoded in dem zusammenhang. (48000 ist ja die empfohlene sampling rate)
nur habe ich derzeit bei start und stop aus mopidy ca. 1-2 sekunden verzögerung. da wird wohl der fifo erst aufgebraucht.
Für das Thema announcements kam mir folgender gedanke: billige bluetooth boxen und aus mopidy nicht mit fifo raus sondern mit pulseaudio und einer fifo sink, dann könnte man das kombinieren.
das mit dem 1-2 Sekunden habe ich mit allen Quellen, das ist wirklich der Puffer. Bei der Bedienung etwas doof, aber es geht. Hab mir noch nicht angesehen ob sich das verkürzen lässt.
Warum willst du denn 44100 haben? Weil das die Samplingrate der Quelle ist, also aus Qualitätsgründen?
Bluetooth sagst du, weil du andere Boxen normalerweise nicht eingeschaltet hast, richtig?
Announcement das sind bei mir eig. 2 Themen:
1. Announcements die mit dem Rest nix zu tun haben. Z.b. dass die Waschmaschine fertig ist, oder dass die Biotonne raus muss. Die kommen auch vor wenn keiner Musik hört. Die kommen bei mir im Moment aus so einem Homematic Steckdosen Ding und dann eben aus denjenigen Boxen, die gerade an sind. Komplett über PA. Kann eig. auch so bleiben.
2. Audio-Feedback an einzelne Clients, die keine eigene Anzeige haben. Wenn mein Kind ne Playlist wechselt soll ja ne Rückmeldung kommen, sowas wie "du hörst jetzt playlist nr 23". Dieser Ton gehört also nicht zu einem Snapcast Stream, sondern fest zu einem Client, also dem, an dem gerade bedient wird. War mit PA kein Problem. Kann ggf. weiter über PA laufen. Da rufe ich einfach ein Script auf, das macht "EXPORT PULSE_SERVER=<ip von kind1>; aplay temp.wav" usw. wobei hier das temp.wav vorher automatisch generiert wird.
Kopfschmerzen macht mir noch die Überlegung, wie man an sich 2 unabhängige Systeme in einer gemeinsamen GUI bzw. einer gemeinsamen Schnittstelle bedienen kann. Also einerseits die Quelle also meinetwegen Mopidy und zweitens die Streamverteilung an die Clients also Snapcast. Das habe ich mit meinem alten Tool über die Funkfernbedienungen prinzipiell gelöst, aber in einem GUI, egal ob Webif, Smartvisu, KODI Plugin, etc. etc. ist das vll etwas komplizierter.
Wegen dem Lag fällt mir nur ein, den fifo möglichst klein zu machen ode die clients zu muten.
Die 44100 habe ich nur weil ich Probleme mit 48000 mit dem 4.2/4.4 android clients hatte.
Ja, die Announcements waren für always-on abseits von multiroom audio gedacht. (mein Surround Receiver braucht 50+ W im Standby zB ;) ) Dachte da an einen Sack mit BT Lautsprechern. Aber wie du sagst eigentlich ist das ein anderes Thema.
Wegen Visualisierung wäre mein Plan ein Widget, dass für die Kombi MPD/Snapcast auf Fhem Seite gedacht ist. Mit einer Reihe http://docu.smartvisu.de/2.8/index.php?page=basic/widget_basic.dual Buttons mit denen ich beim Player Zonen dazuschalten kann.
Natürlich könnte man es auch umgekehrt machen und pro Sound-Zone die Quell-Zone auswählt ;)
Ich halte den ersten Ansatz für natürlicher. Eine Quelle ist im Default einer Zone zugeordnet. Nur in besonderen Fällen schaltet man andere Räume dazu.
Der Wunsch "Ich will jetzt im Wohnzimmer meine Weihnachtsplaylist hören" führt dazu dass im Wohnzimmer auf Play drücken will. Und nicht dass man sich mal einen freien Stream sucht, da auf Play drückt, und dann das WZ dahin schaltet. Hoffe das macht so Sinn :)
Ich glaube auch dass das "Such mir einen freien Player für die Audiozone in der ich stehe" ein Randgruppenszenario ist ;)
Eine Frage die ich mir stelle ist ob man den Player zwischen den Instanzen umschalten können lassen muss oder ob jeder Player einem Raum zugeordnet ist.
Hast du eigentlich auch Zonen die knapp beinander liegen?
Ich habe zB eine große Wohnküche mit angrenzender Terrasse. Die Hauptbeschallung kommt von der Surround-Anlage die auf die Couch eingemessen ist. Die Terrasse hängt an der Zone2 des Verstärkers. In der Küche steht ein Android Radio.
Ich habe jetzt fürs Snapcast-Testen Snapcast am Android Mediaplayer der an der Surround-Anlage und am Android-Radio installiert. Leider habe ich da eine Verzögerung (der Mediaplayer hängt auch am LAN im Gegensatz zum Radio=
In meinem Setup habe ich 2 Kinderzimmer im 1. OG. Wenn da die Türen offen sind, sind sie in Hörreicheweite. Normalerweise hört jedes Kind sein eigenes Zeug aber manchmal finden sie es toll, sich zusammenzuschalten. Beide mit PI1 und billigen Aktivboxen und USB Sound.
Meine Küche grenzt ans Wohnzimmer. Wohnzimmer ist jetzt PI3 mit Kodi und 5.1 Receiver. Da kämpfe ich noch mit dem Sharing. Siehe auch hier: http://forum.kodi.tv/showthread.php?tid=300326 (http://forum.kodi.tv/showthread.php?tid=300326).
Es wird oft so sein, dass man Küche + WZ gleichzeitig bespielen will. Mal aber nur das WZ, mal nur die Küche.
Und dann gibts noch Situationen da will man den vollen Partymodus, überall das gleiche.
In meinem GUI-losen Bedienkonzept funktioniert es ja so, dass ich in einem Raum sitzend entscheide, dass ich jetzt mal woanders mithöre. Daher hab ich im Snapcast Modul ja auch das "set stream next" eingebaut, dann kann man einfach mal durchschalten. Eig. könnte ich da die Streams überspringen, die idle sind.
So ein GUI müsste anzeigen, welche Streams (ausser dem "eigenen") noch zur Verfügung stehen und die Möglichkeit geben, sich auf diese aufzuschalten. Also wenn man sich so normaler Player-Controls vorstellt wäre das für mich einfach noch eine Liste der Fremdstreams da drunter.
Das ganze Setup geht dann davon aus, dass jeder Stream erstmal einen Standardclient hat. Bei mir habe ich jetzt 4 Streams, die heissen Kind1, Kind2, Küche, WZ, und 4 Clients, die heissen genau so.
Zitat von: unimatrix am 12 Dezember 2016, 10:33:24
So ein GUI müsste anzeigen, welche Streams (ausser dem "eigenen") noch zur Verfügung stehen und die Möglichkeit geben, sich auf diese aufzuschalten. Also wenn man sich so normaler Player-Controls vorstellt wäre das für mich einfach noch eine Liste der Fremdstreams da drunter.
Das wäre allerdings Szenario 2 ;) - in dem ich Audiozonen habe und Player-Streams reinschalte. Aber das eine schließt das andere nicht aus ;) Ich muss mir am Abend mal auf Papier aufzeichnen (da kann ich dann auch das Modul mal testen) was wir für ein Datenmodel bräuchten um das Sauber zu realisieren mit Smartvisu
je länger ich darüber nachdenke, desto sinnvoller ercheint es mir die Controls für das Playback und die Snapcaststeuerung zu trennen, dann aber geschickt auf einer Seite zueinander anzuordnen.
Dann könnte man auch Schnellwahltasten einbauen, um typische Szenarien aufzuschalten, oder sowas wie "Mute all" usw. Solche Funktionen baue ich gerade direkt ins Modul.
Wie gesagt, ich fände MR-Audio-Steuerung als Modul, dass ein IO-Modul verwendet sehr sauber.
Nachdem ich aus der Datenbank-Ecke komme ist natürlich für mich ein Zone1reading1, Zone2reading1 mäßig ;) wenngleich ich weiß, dass es oft in FHEM so gemacht wird. (proplanta ist auch so ein Kandidat)
Ganz verrückt: per autocreate jede Snapcast Zone als eigene Audiodevice anlegen (bin noch unentschlossen ob es so eine gute Idee ist) Würde aber den getrennten Playern als Quelle entsprechen.
Btw. die Features die bei Snapcast für die Develop angeteasert werden klingen interessant, was mir aber noch abgeht ist zB ein automatisches Einmessen der Latenz zB durch Ping auf Client etc.
Idee mit Subdevices hatte ich auch schon. Vll. kann man die dumm halten und eig. nur als Wrapper nehmen und alle Funktionen im Hauptmodul lassen. Ich schlaf mal drüber. Dann koennte man die Reading1, Reading2 usw. lassen und die Submodule dann per MAC definieren und frei benennen. Ich hab wenig Ahnung von Audio. K.a. ob mit der Pinglatenz irgendwas anzufangen wäre.
Ich habe mich vor längerer Zeit mit dem Thema beschäftigt und da war unterer anderem das Thema dass NTP nicht ausreicht von der Genauigkeit zum Messen der Latenz die man wirklich braucht für Audio synchronisieren aber das kann auch eher akademisch gewesen sein.
Ein Ping wäre Mal ein Hinweis auf die Latenz Korrektur die man braucht
Gesendet von meinem MI 5 mit Tapatalk
Zum Thema ob man aus dem Ping etwas ablesen kann (vom mopidy server zu den drei Snapcast-Clients)
[sysadmin@arch-server ~]$ [sysadmin@arch-server ~]$ ping multiroomaudio-wohnzimmer-wien
PING multiroomaudio-wohnzimmer-wien.lan (10.0.0.165) 56(84) bytes of data.
64 bytes from multiroomaudio-wohnzimmer-wien.local (10.0.0.165): icmp_seq=1 ttl=64 time=0.668 ms
64 bytes from multiroomaudio-wohnzimmer-wien.local (10.0.0.165): icmp_seq=2 ttl=64 time=0.603 ms
^C
--- multiroomaudio-wohnzimmer-wien.lan ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.603/0.635/0.668/0.041 ms
[sysadmin@arch-server ~]$ ping touch-radio-kueche-wien
PING touch-radio-kueche-wien.lan (10.0.0.189) 56(84) bytes of data.
64 bytes from Android.local (10.0.0.189): icmp_seq=1 ttl=64 time=4.15 ms
64 bytes from Android.local (10.0.0.189): icmp_seq=2 ttl=64 time=4.07 ms
^C
--- touch-radio-kueche-wien.lan ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 4.071/4.114/4.158/0.077 ms
[sysadmin@arch-server ~]$ ping 10.0.0.142
PING 10.0.0.142 (10.0.0.142) 56(84) bytes of data.
64 bytes from 10.0.0.142: icmp_seq=1 ttl=64 time=1.52 ms
64 bytes from 10.0.0.142: icmp_seq=2 ttl=64 time=2.76 ms
64 bytes from 10.0.0.142: icmp_seq=3 ttl=64 time=2.51 ms
64 bytes from 10.0.0.142: icmp_seq=4 ttl=64 time=2.57 ms
^C
--- 10.0.0.142 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3007ms
rtt min/avg/max/mdev = 1.529/2.347/2.767/0.481 ms
Lustige Erfahrung beim "spielen" in der Küche, das Küchenradio braucht weniger Latenz als der Mediaplayer über LAN??
Gesendet von meinem MI 5 mit Tapatalk
hm, mir ist nicht klar, von welchen Faktoren das abhängt, und vor allem, ob das stabil ist. Wenn es sich ändert, bringt ja jede Einstellung nix.
Wobei der Mediaplayer gleichzeitig KODi laufen hat, bin gespannt was bei android passiert wenn ich KODi und snapcast abwechselnd laufen habe
Gesendet von meinem MI 5 mit Tapatalk
Ok, das ist zugegebenermaßen sehr cool, KODi mit passthrough und snapcast kooexistieren :)
Während KODi idled kann ich einfach snapcast Audio anspielen, während passthrough kommt Müll (bei gleichzeitig keine Überraschung)
Ich mache aber in KODi kein upsampling, ich Stelle im 2ch Fall den Receiver auf 5.1 Stereo oder opimizer.
Gesendet von meinem MI 5 mit Tapatalk
Da fällt mir gleich ein mit einem doif zu verhindern die zone einzuschalten während KODi abspielt
Gesendet von meinem MI 5 mit Tapatalk
so rum ist es leicht. aber die Zone abschalten, direkt bevor Kodi abspielen will, ist etwas schwieriger.
Ein bisserl denken muss man dem User schon noch lassen. Und wie viele außer uns haben KODi mit Passthrough und snapcast auf der gleichen device ;)
Gesendet von meinem MI 5 mit Tapatalk
verstehe ich auch nicht wieso ein so vollkommen typisches Setup so wenig verbreitet ist ;) ... ich will Snapcast nativ in kodi :)
Es wird langsam ;) (http://uploads.tapatalk-cdn.com/20161212/7144e460e2921332eb104d1bd6e84a6f.jpg)
Gesendet von meinem MI 5 mit Tapatalk
Android gewinnt mit snapcast doch an Wert ;) vielleicht doch pro Raum ein Tablet und davon das Audio Weg ;)
Gesendet von meinem MI 5 mit Tapatalk
Beim Versuch das Modul zu laden hängt sich leider FHEM auf:
2016.12.12 23:39:36 1: PERL WARNING: Scalar value @values[$i+1] better written as $values[$i+1] at ./FHEM/96_Snapcast.pm line 325.
2016.12.12 23:39:36 3: Opening multiroomaudio.multimedia.wohnung device 10.0.0.154:1705
2016.12.12 23:39:36 3: {"jsonrpc":"2.0","id":1,"method":"Server.GetStatus"}
unexpected end of string while parsing JSON string, at character offset 4096 (before "(end of string)") at ./FHEM/96_Snapcast.pm line 372.
Was mich etwas mühsam ist, wenn man den snapserver Service neu startet muss man die snapclients neu starten/stoppen/starten bevor es wieder geht. Vielleicht geht mit amad2 etwas dazu.
Btw wenn wir die snapclients als einzelne devices hätten und den snapserver wäre es wieder der gleiche Aufbau wie bei dem ersten pulseaudio Modul von dir.
Den Traffic im wifi merkt man schon. (http://uploads.tapatalk-cdn.com/20161213/e16ed06a8ade722461a33a54a8cbad59.jpg)
Gesendet von meinem MI 5 mit Tapatalk
du meinst den Android Client oder? Er macht ja was, aber da scheints nen Bug zu geben. Der LInux Client connected sich sofort wieder.
Ja das mit dem Clientmodul ist richtig, werd ich so machen. Allerdings wird ja gerade offenbar nochmal die JSON Schnittstelle erweitert. Da muss ich dann leider nochmal umbauen.
Also dann werden wir einen MR-Client haben, und der hat dann als Backend eine Kombi aus dem SCServermodul, einem MPD-Modul und ggf. noch mehr.
Mir ist aufgefallen, dass ich beim ersten Versuch das sc Modul einzurichten einen Raum mit Umlaut hatte, aber selbst als ich den umbenannt hatte stürzt nach wie vor fhem beim define ab.
Gesendet von meinem MI 5 mit Tapatalk
ok danke, versuche ich nachzustellen. Offenbar plant ja der SC Entwickler die Einbringung von Zonen als Zwischenebene. Ich muss mir das noch im Devel Branch ansehen und überlegen, wie sich das dann auf die Idee mit den Client-Modulinstanzen auswirkt.
Ich habe jetzt Snapcast auf einem anderen Server installiert und das FHEM modul crasht noch immer, aber wenn ich das JSON direkt hole kriege ich untenstehendes (da bin ich wohl zu doof für die snapcast config?
{"error":{"code":-32700,"message":"parse error - unexpected 'G'"},"id":null,"jsonrpc":"2.0"}
{"error":{"code":-32700,"message":"parse error - unexpected 'H'"},"id":null,"jsonrpc":"2.0"}
{"error":{"code":-32700,"message":"parse error - unexpected 'C'"},"id":null,"jsonrpc":"2.0"}
{"error":{"code":-32700,"message":"parse error - unexpected 'C'"},"id":null,"jsonrpc":"2.0"}
{"error":{"code":-32700,"message":"parse error - unexpected 'U'"},"id":null,"jsonrpc":"2.0"}
{"error":{"code":-32700,"message":"parse error - unexpected 'U'"},"id":null,"jsonrpc":"2.0"}
{"error":{"code":-32700,"message":"parse error - unexpected 'A'"},"id":null,"jsonrpc":"2.0"}
{"error":{"code":-32700,"message":"parse error - unexpected 'A'"},"id":null,"jsonrpc":"2.0"}
{"error":{"code":-32700,"message":"parse error - unexpected 'A'"},"id":null,"jsonrpc":"2.0"}
{"jsonrpc":"2.0","method":"Client.OnDisconnect","params":{"data":{"config":{"latency":0,"name":"","stream":"Wohnzimmer","volume":{"muted":false,"percent":100}},"connected":false,"host":{"arch":"arm64-v8a","ip":"10.0.0.196","mac":"78:02:f8:21:77:7a","name":"MI5-AlexPhone","os":"Android 6.0"},"lastSeen":{"sec":1481838015,"usec":591092},"snapclient":{"name":"Snapclient","protocolVersion":2,"version":"0.10.0"}}}}
im letzten GIT stand ist wohl ein Bug, mein Fehler. kanns aber gerade nicht ändern, erst morgen.
hm Kommando zurück eig. müsste es gehen. Kann den Fehler nicht nachstellen. Vll liegt es an irgendeinem Modul. Bekommst du eine Fehlermeldung im Log beim Absturz? Was heisst Configl. Mehr als die IP musst du ja nicht angeben, also bei dir halt define mySnap Snapcast 10.0.0.x
Das ist neben dem PA Zeug mein erstes FHEM Modul...
Hi,
die Fehlermeldung ist in Post #74. (nexpected end of string while parsing JSON string, at character offset 4096)
Ich würde vermuten, es liegt an den diesem Zeug, dass bei mir im JSON drinnen ist wenn es direkt auf Port 1705 hole: {"error":{"code":-32700,"message":"parse error - unexpected 'G'"},"id":null,"jsonrpc":"2.0"}
Möglicherweise eine alte libjson bei mir ? (fhem rennt auf meinem Fileserver der noch auf Wheezy läuft)
Nachdem mopidy multi Instanz erstaunlich instabil ist auf meinem Arch Server innerhalb einer virtual Box (eigentlich war da das Gegenteil das Ziel ;) ) und ich im snapcast Log auch dauernd End of File Fehler habe könnte es auch an einer fehlerhaften Installation liegen (meine Arch Desktop Maschine die ich vorher zum.testen verwendet habe war da unproblematischer)
Anyway, was schon cool ist bei snapcast, dass ich die bestehenden Mediaplayer in den Räumen verwenden kann und mich nicht darum kümmern muss, die Eingänge beim Lautsprecher umzuschalten.
Gesendet von meinem MI 5 mit Tapatalk
Update: zumindest die mopidy instabilität scheint am Ö1 mopidy plugin zu liegen.
Warum alledings snapcast zB beim Versuch das JSON direkt zu holen mit CHrome abstürzt ist mir eher schleierhaft.
Ich habe dein Modul bei mir in Betrieb genommen und kann bestätigen, dass alles soweit super klappt. Danke dafür!
In deinen Beispielen haben sich aber kleine Fehler eingeschlichen. das set command muss immer "set <servername> <attribut> <clientname> <wert>" lauten. du hast teilweise attibut und clientname vertauscht. Das musste ich erstmal rausfinden :)
Einen Wunsch, bzw. Frage hätte ich noch:
Meinst du es würde Sinn machen ein command wie "volstepup" und "volstepdown" zu definieren?
Oder ist das überflüssig und über ein simples notify leistbar?
Ich habe momentan noch keine funktionsfähige notify bauen können um die lautstärke eines clients z.B. per Knopfdruck um 10 zu erhöhen.
Hat dazu jemand ein Beispiel?
Mir ist aufgefallen dass dein Modul die readings nicht updated, nachdem ein setbefehl rausgeschickt wird.
Ich habe das jetzt dadurch gelöst, dass ich am ende der Snapcast_set Methode in Zeile 135 noch ein "Snapcast_GetStatus($hash);" hinzugefügt habe.
So, jetzt habe ich sogar ein Debian in einer VM installiert und habe nach wie vor das gleiche Problem. Liegt dann wohl an meiner Config von Snapcast die ich allerdings 1:1 von der github Seite kopiert habe
Oder kann es daran liegen, dass die Server in einer VM laufen? (das würde mich wohl wundern)
root@debianmini:/home/sysadmin# systemctl status snapserver
● snapserver.service - Snapcast server
Loaded: loaded (/lib/systemd/system/snapserver.service; enabled)
Active: active (running) since Die 2016-12-20 22:16:59 CET; 1min 25s ago
Process: 1761 ExecStart=/usr/sbin/snapserver $SNAPSERVER_OPTS (code=exited, status=0/SUCCESS)
Main PID: 1763 (snapserver)
CGroup: /system.slice/snapserver.service
└─1763 /usr/sbin/snapserver -d -s pipe:///tmp/snapfifo_zone1?name=Wohnzimmer&sampleformat=44100:16:2&codec=ogg
Dez 20 22:16:59 debianmini systemd[1]: Starting Snapcast server...
Dez 20 22:16:59 debianmini snapserver[1761]: Settings file: /var/lib/snapcast/server.json
Dez 20 22:16:59 debianmini snapserver[1761]: pipe:///tmp/snapfifo_zone1?name=Wohnzimmer&sampleformat=44100:16:2&codec=ogg
Dez 20 22:16:59 debianmini snapserver[1763]: daemon started
Dez 20 22:16:59 debianmini systemd[1]: Started Snapcast server.
Dez 20 22:17:25 debianmini snapserver[1763]: ControlServer::NewConnection: 10.0.0.236
Dez 20 22:17:25 debianmini snapserver[1763]: Exception in ControlSession::reader(): read_until: End of file
Dez 20 22:18:09 debianmini snapserver[1763]: ControlServer::NewConnection: 10.0.0.178
Dez 20 22:18:09 debianmini snapserver[1763]: ControlServer::NewConnection: 10.0.0.178
Dez 20 22:18:19 debianmini snapserver[1763]: Exception in ControlSession::reader(): read_until: End of file
Was auch noch strange ist: direct an der Installation ohne dass ich einen Client auf die neue IP umgestellt hätte kommen schon new connection einträge im Log
Dez 20 22:21:57 debianmini snapserver[1874]: ControlServer::NewConnection: 10.0.0.178
Die Ports 1704 und 1705 werden weitergeleitet?
Ich würde tippen dass an deiner Netzwerkconfig der VMs etwas nicht passt. Der Host agiert bei dem Setup ja irgendwie als Router für die VM Gäste und eventuell sehen alle Verbindungen von verschiedenen Clients für den Snapserver so aus als kämen sie alle von einem Client mit der IP des Hosts.
Ich hatte auch mal ähnliche Probleme beim Netzwerksetup einer anderen App in einer VM und da lag das an solchen Geschichten. Aber genau krieg ich das auch nicht mehr zusammen.
ich habe eigentlich die VMs immer auf "bridged" gestellt sprich die bekommen vom normalen router ihre IP. Aber es kann natürlich trotzdem was sein mit dem VM-Setup.
Doof ist nur, dass meine "echten" server mit debian wheezy laufen und dort nichtmal selbst kompilieren hinhaut.
so, ich habe ein fhem auf arch installiert und (abgesehen davon, dass das aur package quasi nix richtig macht) das snapcast modul funktioniert! scheint also an libs auf wheezy zu liegen, dass es mir dort fhem in den tod reißt.
gibt es eigentlich was besseres als fhem2fhem mittlerweile um 2fhem instanzen zu verbinden?
Hi, ich habe jetzt meine Arch VM aufgegeben und eine Debian Jessie VM für den Musik Server gemacht. Funktioniert jetzt mit 7 Zonen problemlos. Das einzige das mir in Kombi mit mopidy auffällt, dass mopidy nach dem Druck auf Pause oft noch viele Sekunden nachspielt (das könnte ja noch der fifo sein) aber da auch fhem dann einige Sekunden hängt vermute ich eher ein mopidy Lock Up. Hat das Problem sonst jemand?
Hallo,
bin zurück aus dem Urlaub und werd jetzt wieder loslegen. Bei mir ist die FIFO Pause ca. 1-2 Sekunden.
Warum hängt dann FHEM? Nutzt du jetzt das Snapcast Modul oder das MPD Modul oder beides?
Problem mit dem Snapcast Modul ist dass im Moment ja einiges an der Schnittstelle bei Snapcast gedreht wird, das aber noch nicht fertig ist.
Mopidy habe ich noch keinem Dauertest unterzogen aber ich habe Beobachtungen wo die einzelnen Instanzen mal auf 100% CPU Last gehen und dann langsam reagieren.
Zitat von: LeoSum am 19 Dezember 2016, 23:24:34
Mir ist aufgefallen dass dein Modul die readings nicht updated, nachdem ein setbefehl rausgeschickt wird.
Ich habe das jetzt dadurch gelöst, dass ich am ende der Snapcast_set Methode in Zeile 135 noch ein "Snapcast_GetStatus($hash);" hinzugefügt habe.
Hallo, kann ich nicht reproduzieren. Das Modul hält eine offene Verbindung zum Snapcast Server und sollte eig. alle Readings updaten, die auch vom Server upgedated werden. Das betrifft ja gerade auch solche Updates, die von einem anderen Client, z.B. vom Android Client aus, angetriggert werden. Wenn ich bei mir im Android Client z.B. Mute und UnMute dann sehe ich das sofort in den Readings.
Ein Extra GetStatus wollte ich eigentlich vermeiden. Kannst du das Problem genauer beschreiben?
Zitat von: LeoSum am 19 Dezember 2016, 23:12:30
In deinen Beispielen haben sich aber kleine Fehler eingeschlichen. das set command muss immer "set <servername> <attribut> <clientname> <wert>" lauten. du hast teilweise attibut und clientname vertauscht. Das musste ich erstmal rausfinden :)
meinst du in der Commandref oder hier im Forum? Commandref habe ich gerade nochmal durchgeschaut und scheint zu stimmen, aber vll. bin ich da als Autor blind :)
Zitat von: LeoSum am 19 Dezember 2016, 23:12:30
Meinst du es würde Sinn machen ein command wie "volstepup" und "volstepdown" zu definieren?
Das ist direkt im Modul geplant
Zitat von: drdownload am 04 Januar 2017, 21:18:06
Hi, ich habe jetzt meine Arch VM aufgegeben und eine Debian Jessie VM für den Musik Server gemacht. Funktioniert jetzt mit 7 Zonen problemlos. Das einzige das mir in Kombi mit mopidy auffällt, dass mopidy nach dem Druck auf Pause oft noch viele Sekunden nachspielt (das könnte ja noch der fifo sein) aber da auch fhem dann einige Sekunden hängt vermute ich eher ein mopidy Lock Up. Hat das Problem sonst jemand?
Kann ich reproduzieren. Ist IMHO ein Problem mit dem MPD Modul. Dem muss ich auf den Grund gehen sonst ist das ja unbenutzbar.
Das Problem ist wohl die Kombi aus mopidy filesink und snapcast. Wenn ich einfach auf eine alsasink abspiele läuft mopidy.
Das mpd Modul lockup kommt auch nur vor wenn ich versuche in mopidy zu stoppen etc.
CPU Last ist unter Debian jetzt kein problem mehr ca 5% pro transcoding instanz
Der blocking call von Mpd Modul ist aber auch so grausig
aus meiner Sicht braucht man da gar keinen Blocking Call....uff...das sieht nach Arbeit aus die ich mir gar nicht antun wollte...
Ich hab mich Mal kurz gespielt, wenn ich die Fifos von snapcast anlegen lasse und dann mopidy die ownership gebe bin ich immerhin auf 2s lagging unten
edit: pff leider doch nicht, verstehe ich nicht, manchmal geht es sofort, manachmal hängt es 2-3 min. bevor es stoppt (und in der Zeit ist auch FHEM blockiert)
egal ob spotify, stream oder lokal.
ok das habe ich schon immer so gemacht, wahrscheinlich durch Zufall.
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. IMHO koennte man einfach die Verbindung auflassen so wie ich das mit dem SC Modul auch mache und dann gibts auch keine Blocking Calls, keine Timeouts, oder sonst irgendetwas.
Bei mir ist es jetzt leider so dass FHEM für immer einfriert wenn ich ein MPD Modul definiere und dann per Android Native Mopidy Client etwas tue.
Ja, das Verhalten kenne ich.
du kennst es oder ist es bei dir auch immer so bzw. nur manchmal? ich versuche, dem auf den Grund zu gehen. danke :)
nach attr mpd player mopidy tritt das problem nicht mehr auf. na toll.
Zitat von: LeoSum am 19 Dezember 2016, 23:12:30
Meinst du es würde Sinn machen ein command wie "volstepup" und "volstepdown" zu definieren?
Ist implementiert und auf dem GIT.
Beispiel: set snap myclient volume -12
..also einfach ein + oder - davor setzen.
Werde bei Bedarf noch ein Attribut fuer eine dort festlegbare Stepweite anlegen.
https://forum.fhem.de/index.php/topic,64511.0.html
Das sieht interessant aus in Richtung Visualisierung, das System ist ja das gleiche wie bei uns. Auch hier hört ein kanal woanders mit. Nur mal als Hinweis.
Ich poste ab jetzt alle Dinge, die direkt mit Snapcast zu tun haben, nur noch in den Snapcast Thread. Heute kommt noch ein Update.
Spannend mein FHEM weiß noch nix von dem attr im Dropdown, muss wohl mal ein Update machen ;) - aber super das es was hilft
das Modul ist ja noch nicht mal im SVN. Musst man sich manuell aus dem GIT holen.
Ah, da hat mich die Erinnerung der Installationsgenese verlassen
Gesendet von meinem MI 5 mit Tapatalk
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.
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 ;)
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 \
Zitat von: unimatrix am 10 Januar 2017, 19:47:01
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)
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.
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
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.
Zitat von: unimatrix am 09 Januar 2017, 20:38:13
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.
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 :)
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 ;)
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?
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 ;)
ok verstanden. Aber das locken hilft ja dann nur bedingt, weil dann kann derjenige, der dann ins Büro geht um die Schlagerparade zu hören ja nicht hören kann, weil der Player durch das Bad gelockt ist.
Ich hielte es für sinnvoll, wenn derjenige der ins Bad geht dann einfach den State des Büro-Players mit zum Bad-Player transferiert. So könnte man 2 Vorgänge unterscheiden:
- Büro spielt schon, nun passiert eins von 2 Dingen:
- Im Bad hört man die schöne Musik im Büro und will auch mithören. Man drückt den Zuschaltknopf. Sollte es nicht noch woanders Musik geben, die gerade läuft, ist man sofort beim Büro "mit dabei". Natürlich kann man jetzt auch böse sein und einfach andere Musik anmachen. Man steuert immer den Player, auf dem man gerade zuhört. Aber das will ich nicht auch noch mit technischen Mitteln einschränken
- Im Büro denkt man sich, oh die Musik ist so toll, da soll das Bad nicht außen vor bleiben. Man schaltet das Bad vom Büro aus mit hinzu. Im Ergebnis kommt das gleiche raus, das Bad hört mit, abgespielt wird aber auf dem dem Büro fest zugeordneten Player.
- Man fängt wie von dir beschrieben im Büro an und geht jetzt längerfristig ins Bad. Das merkt man entweder
- schon im Büro und drückt auf den Knopf "Transfer ins Bad" (nutzt man eine Fernbedienung müssten das meistens 2 Knöpfe sein es sei denn man hat dafür einen Shortcut weil man es oft macht
- oder erst im Bad, dann drückt man eben den Knopf "Transfer von ..:" womit man dann das gleich erreicht. Je nach Konfiguration / Attribut hört dann das Büro entweder sofort, oder nach eingestellter Zeit, oder gar nicht mit dem Spielen auf, in jedem Fall ist es aber sofort unabhängig und eine Änderung am Büroplayer wirkt sich nicht mehr aufs Bad aus.
Das ganze basiert also auf der Vorstellung, dass jeder Raum bzw. jeder Client einen fest zugeorneten Zuspieler hat (also bleiben wir mal bei Mopidy). Dem entgegen stünde ein System, wo eine nicht fest zugeordnete Anzahl von Playern frei zur Verfügung stände, und sich das System diese irgendwie intelligent selber suchen würde. Ich bleibe bis auf weiteres aber bei der Festzuordnung.
Obiges Schema lässt sich komplett ohne GUI nur mit Fernbedienung bedienen. Das ist für mich immer Vorraussetzung, einfach weil es meine eigene Anwendung ist. Es lässt sich aber IMHO auch gut in einer GUI darstellen, und zwar kompatibel zu den AVGuidlines die hier auch in anderen Modulen verwendet werden.
Kurzes Update: die Kombi aus mopidy to pulseaudio to snapcast hat alle nervigen Fehler beseitigt und rennt sehr stabil
@unimatrix: hier sollte auch dein einmixen über pulseaudio gehen
Gesendet von meinem MI 5 mit Tapatalk
Ich habe lustigerweise mit meinen Kollegen auch genau das Szenario "wieso hat der Player überhaupt eine fixe Zuordnung" diskutiert.
So nett auch ein Vorrat an Playern wäre die man sich einfach dynamisch hintereinander nimmt, meistens ist die Anforderungen ja einfach mach im Wohnzimmer Musik und nach einem bisserl Schulung der großen und kleinen Nutzer hat es jeder heraußen denke ich. In smartvisu gebe ich sicher einen Status wie playing prominent dazu
Gesendet von meinem MI 5 mit Tapatalk
hi, ich habe jetzt versucht auf meinem musik server (debian jessie) fhem zu installieren und leider reißt das snapcast modul fhem hier in den abgrund.
hier mal aus dem fhem-log:
2017.01.14 19:13:06 3: Opening test device server-musik-wien.lan:1705
2017.01.14 19:13:06 3: {"jsonrpc":"2.0","method":"Server.GetStatus","id":1}
2017.01.14 19:13:06 2: Invalid Response from Snapcast,ignoring result: {"id":1,"jsonrpc":"2.0","result":{"clients":[{"config":{"latency":0,"name":"Mi5 Test","stream":"Wohnzimmer","volume":{"muted":false,"percent":100}},"connected":true,"host":{"arch":"arm64-v8a","ip":"10.0.0.196","mac":"78:02:f8:21:77:7a","name":"MI5-AlexPhone","os":"Android 6.0"},"lastSeen":{"sec":1484417060,"usec":205165},"snapclient":{"name":"Snapclient","protocolVersion":2,"version":"0.10.0"}},{"config":{"latency":0,"name":"Radio Küche","stream":"Wohnzimmer","volume":{"muted":false,"percent":45}},"connected":true,"host":{"arch":"armeabi-v7a","ip":"10.0.0.189","mac":"a0:f4:59:c7:c3:95","name":"android-740a459bf24dd0a","os":"Android 4.2.2"},"lastSeen":{"sec":1484417582,"usec":885300},"snapclient":{"name":"Snapclient","protocolVersion":2,"version":"0.10.0"}},{"config":{"latency":0,"name":"Yamaha Wohnzimmer","stream":"Wohnzimmer","volume":{"muted":false,"percent":67}},"connected":true,"host":{"arch":"armeabi-v7a","ip":"10.0.0.117","mac":"08:61:51:20:54:37","name":"android-58377744637334b8","os":"Android 4.4.2"},"lastSeen":{"sec":1484417582,"usec":574114},"snapclient":{"name":"Snapclient","protocolVersion":2,"version":"0.10.0"}},{"config":{"latency":22,"name":"Radio Badezimmer","stream":"Wohnzimmer","volume":{"muted":true,"percent":68}},"connected":false,"host":{"arch":"armeabi-v7a","ip":"10.0.0.105","mac":"30:39:26:d8:c8:c3","name":"xperiap-alex","os":"Android 5.1.1"},"lastSeen":{"sec":1484375837,"usec":736743},"snapclient":{"name":"Snapclient","protocolVersion":2,"version":"0.10.0"}},{"config":{"latency":2,"name":"Marantz Büro","stream":"Wohnzimmer","volume":{"muted":true,"percent":47}},"connected":true,"host":{"arch":"armeabi-v7a","ip":"10.0.0.142","mac":"e0:b9:4d:1d:3f:b6","name":"android-13b65b673dcc71d4","os":"Android 6.0.1"},"lastSeen":{"sec":1484417583,"usec":90479},"snapclient":{"name":"Snapclient","protocolVersion":2,"version":"0.10.0"}},{"config":{"latency":0,"name":"Office","stream":"Wohnzimmer","volume":{"muted":true,"percent":33}},"connected":false,"host":{"arch":"armeabi-v7a","ip":"10.0.0.138","mac":"3c:cf:5b:99:30:64","name":"android-66f49b5f8c6823b7","os":"Android 5.1.1"},"lastSeen":{"sec":1483898839,"usec":448375},"snapclient":{"name":"Snapclient","protocolVersion":2,"version":"0.10.0"}}],"server":{"host":{"arch":"x86_64","ip":"","mac":"","name":"debianmini","os":"Debian GNU/Linux 8.6 (jessie)"},"snapserver":{"controlProtocolVersion":1,"name":"Snapserver","protocolVersion":1,"version":"0.10.0"}},"streams":[{"id":"Wohnzimmer","status":"idle","uri":{"fragment":"","host":"","path":"/tmp/pulsefifo_1","query":{"buffer_ms":"20","codec":"ogg","mode":"read","name":"Wohnzimmer","sampleformat":"48000:16:2"},"raw":"pipe:///tmp/pulsefifo_1?name=Wohnzimmer&sampleformat=48000:16:2&codec=ogg&mode=read","scheme":"pipe"}},{"id":"Badezimmer","status":"idle","uri":{"fragment":"","host":"","path":"/tmp/pulsefifo_2","query":{"buffer_ms":"20","codec":"ogg","mode":"read","name":"Badezimmer","sampleformat":"48000:16:2"},"raw":"pipe:///tmp/pulsefifo_2?name=Badezimmer&sampleformat=48000:16:2&codec=ogg&mode=read","scheme":"pipe"}},{"id":"Büro","status":"idle","uri":{"fragment":"","host":"","path":"/tmp/pulsefifo_3","query":{"buffer_ms":"20","codec":"ogg","mode":"read","name":"Büro","sampleformat":"48000:16:2"},"raw":"pipe:///tmp/pulsefifo_3?name=Büro&sampleformat=48000:16:2&codec=ogg&mode=read","scheme":"pipe"}},{"id":"Schlafzimmer","status":"idle","uri":{"fragment":"","host":"","path":"/tmp/pulsefifo_4","query":{"buffer_ms":"20","codec":"ogg","mode":"read","name":"Schlafzimmer","sampleformat":"48000:16:2"},"raw":"pipe:///tmp/pulsefifo_4?name=Schlafzimmer&sampleformat=48000:16:2&codec=ogg&mode=read","scheme":"pipe"}},{"id":"Kinderzimmer","status":"idle","uri":{"fragment":"","host":"","path":"/tmp/snapfifo_5","query":{"buffer_ms":"20","codec":"ogg","mode":"read","name":"Kinderzimmer","sampleformat":"48000:16:2"},"raw":"pipe:///tmp/snapfifo_5?name=Kinderzimmer&sampleformat=48000:16:2&codec=ogg&mode=read","scheme":"pipe"}},{"id":"T6","status":"idle","uri":{"fragment":"","host":"","path":"/tmp/snapfifo_6","query":{"buffer_ms":"20","
2017.01.14 19:13:06 3: test device opened
2017.01.14 19:13:06 3: codec":"ogg","mode":"read","name":"T6","sampleformat":"48000:16:2"},"raw":"pipe:///tmp/snapfifo_6?name=T6&sampleformat=48000:16:2&codec=ogg&mode=read","scheme":"pipe"}},{"id":"T4","status":"idle","uri":{"fragment":"","host":"","path":"/tmp/pulsefifo1","query":{"buffer_ms":"20","codec":"ogg","mode":"read","name":"T4","sampleformat":"48000:16:2"},"raw":"pipe:///tmp/pulsefifo1?name=T4&sampleformat=48000:16:2&codec=ogg&mode=read","scheme":"pipe"}}]}}
malformed JSON string, neither array, object, number, string or atom, at character offset 0 (before "codec":"ogg","mode":...") at ./FHEM/96_Snapcast.pm line 240.
dann habe ich den namen büro auf buero geändert:
2017.01.14 19:22:38 2: Invalid Response from Snapcast,ignoring result: {"id":1,"jsonrpc":"2.0","result":{"clients":[{"config":{"latency":0,"name":"Mi5 Test","stream":"Wohnzimmer","volume":{"muted":false,"percent":100}},"connected":false,"host":{"arch":"arm64-v8a","ip":"10.0.0.196","mac":"78:02:f8:21:77:7a","name":"MI5-AlexPhone","os":"Android 6.0"},"lastSeen":{"sec":1484416904,"usec":372248},"snapclient":{"name":"Snapclient","protocolVersion":2,"version":"0.10.0"}},{"config":{"latency":0,"name":"Radio Küche","stream":"Wohnzimmer","volume":{"muted":false,"percent":45}},"connected":false,"host":{"arch":"armeabi-v7a","ip":"10.0.0.189","mac":"a0:f4:59:c7:c3:95","name":"android-740a459bf24dd0a","os":"Android 4.2.2"},"lastSeen":{"sec":1484418035,"usec":553164},"snapclient":{"name":"Snapclient","protocolVersion":2,"version":"0.10.0"}},{"config":{"latency":0,"name":"Yamaha Wohnzimmer","stream":"Wohnzimmer","volume":{"muted":false,"percent":67}},"connected":false,"host":{"arch":"armeabi-v7a","ip":"10.0.0.117","mac":"08:61:51:20:54:37","name":"android-58377744637334b8","os":"Android 4.4.2"},"lastSeen":{"sec":1484418035,"usec":622218},"snapclient":{"name":"Snapclient","protocolVersion":2,"version":"0.10.0"}},{"config":{"latency":22,"name":"Radio Badezimmer","stream":"Wohnzimmer","volume":{"muted":true,"percent":68}},"connected":false,"host":{"arch":"armeabi-v7a","ip":"10.0.0.105","mac":"30:39:26:d8:c8:c3","name":"xperiap-alex","os":"Android 5.1.1"},"lastSeen":{"sec":1484375837,"usec":736743},"snapclient":{"name":"Snapclient","protocolVersion":2,"version":"0.10.0"}},{"config":{"latency":2,"name":"Marantz Büro","stream":"Wohnzimmer","volume":{"muted":true,"percent":47}},"connected":true,"host":{"arch":"armeabi-v7a","ip":"10.0.0.142","mac":"e0:b9:4d:1d:3f:b6","name":"android-13b65b673dcc71d4","os":"Android 6.0.1"},"lastSeen":{"sec":1484418157,"usec":277091},"snapclient":{"name":"Snapclient","protocolVersion":2,"version":"0.10.0"}},{"config":{"latency":0,"name":"Office","stream":"Wohnzimmer","volume":{"muted":true,"percent":33}},"connected":false,"host":{"arch":"armeabi-v7a","ip":"10.0.0.138","mac":"3c:cf:5b:99:30:64","name":"android-66f49b5f8c6823b7","os":"Android 5.1.1"},"lastSeen":{"sec":1483898839,"usec":448375},"snapclient":{"name":"Snapclient","protocolVersion":2,"version":"0.10.0"}}],"server":{"host":{"arch":"x86_64","ip":"","mac":"","name":"debianmini","os":"Debian GNU/Linux 8.6 (jessie)"},"snapserver":{"controlProtocolVersion":1,"name":"Snapserver","protocolVersion":1,"version":"0.10.0"}},"streams":[{"id":"Wohnzimmer","status":"idle","uri":{"fragment":"","host":"","path":"/tmp/pulsefifo_1","query":{"buffer_ms":"20","codec":"ogg","mode":"read","name":"Wohnzimmer","sampleformat":"48000:16:2"},"raw":"pipe:///tmp/pulsefifo_1?name=Wohnzimmer&sampleformat=48000:16:2&codec=ogg&mode=read","scheme":"pipe"}},{"id":"Badezimmer","status":"idle","uri":{"fragment":"","host":"","path":"/tmp/pulsefifo_2","query":{"buffer_ms":"20","codec":"ogg","mode":"read","name":"Badezimmer","sampleformat":"48000:16:2"},"raw":"pipe:///tmp/pulsefifo_2?name=Badezimmer&sampleformat=48000:16:2&codec=ogg&mode=read","scheme":"pipe"}},{"id":"Buero","status":"idle","uri":{"fragment":"","host":"","path":"/tmp/pulsefifo_3","query":{"buffer_ms":"20","codec":"ogg","mode":"read","name":"Buero","sampleformat":"48000:16:2"},"raw":"pipe:///tmp/pulsefifo_3?name=Buero&sampleformat=48000:16:2&codec=ogg&mode=read","scheme":"pipe"}},{"id":"Schlafzimmer","status":"idle","uri":{"fragment":"","host":"","path":"/tmp/pulsefifo_4","query":{"buffer_ms":"20","codec":"ogg","mode":"read","name":"Schlafzimmer","sampleformat":"48000:16:2"},"raw":"pipe:///tmp/pulsefifo_4?name=Schlafzimmer&sampleformat=48000:16:2&codec=ogg&mode=read","scheme":"pipe"}},{"id":"Kinderzimmer","status":"idle","uri":{"fragment":"","host":"","path":"/tmp/snapfifo_5","query":{"buffer_ms":"20","codec":"ogg","mode":"read","name":"Kinderzimmer","sampleformat":"48000:16:2"},"raw":"pipe:///tmp/snapfifo_5?name=Kinderzimmer&sampleformat=48000:16:2&codec=ogg&mode=read","scheme":"pipe"}},{"id":"T6","status":"idle","uri":{"fragment":"","host":"","path":"/tmp/snapfifo_6","query":{"buffer_ms":"2
2017.01.14 19:22:38 3: test device opened
2017.01.14 19:22:38 3: 0","codec":"ogg","mode":"read","name":"T6","sampleformat":"48000:16:2"},"raw":"pipe:///tmp/snapfifo_6?name=T6&sampleformat=48000:16:2&codec=ogg&mode=read","scheme":"pipe"}},{"id":"T4","status":"idle","uri":{"fragment":"","host":"","path":"/tmp/pulsefifo1","query":{"buffer_ms":"20","codec":"ogg","mode":"read","name":"T4","sampleformat":"48000:16:2"},"raw":"pipe:///tmp/pulsefifo1?name=T4&sampleformat=48000:16:2&codec=ogg&mode=read","scheme":"pipe"}}]}}
garbage after JSON object, at character offset 1 (before "","codec":"ogg","mod...") at ./FHEM/96_Snapcast.pm line 240.
ich habe jetzt auch versucht alle clients von umlauten zu befreien.
2017.01.14 19:58:30 2: Invalid Response from Snapcast,ignoring result: {"id":1,"jsonrpc":"2.0","result":{"clients":[{"config":{"latency":0,"name":"Mi5 Test","stream":"Wohnzimmer","volume":{"muted":false,"percent":100}},"connected":false,"host":{"arch":"arm64-v8a","ip":"10.0.0.196","mac":"78:02:f8:21:77:7a","name":"MI5-AlexPhone","os":"Android 6.0"},"lastSeen":{"sec":1484419709,"usec":721519},"snapclient":{"name":"Snapclient","protocolVersion":2,"version":"0.10.0"}},{"config":{"latency":0,"name":"Radio Kitchen","stream":"Wohnzimmer","volume":{"muted":false,"percent":100}},"connected":false,"host":{"arch":"armeabi-v7a","ip":"10.0.0.189","mac":"a0:f4:59:c7:c3:95","name":"android-740a459bf24dd0a","os":"Android 4.2.2"},"lastSeen":{"sec":1484418035,"usec":553164},"snapclient":{"name":"Snapclient","protocolVersion":2,"version":"0.10.0"}},{"config":{"latency":0,"name":"Yamaha Wohnzimmer","stream":"Wohnzimmer","volume":{"muted":false,"percent":67}},"connected":false,"host":{"arch":"armeabi-v7a","ip":"10.0.0.117","mac":"08:61:51:20:54:37","name":"android-58377744637334b8","os":"Android 4.4.2"},"lastSeen":{"sec":1484418035,"usec":622218},"snapclient":{"name":"Snapclient","protocolVersion":2,"version":"0.10.0"}},{"config":{"latency":22,"name":"Radio Badezimmer","stream":"Wohnzimmer","volume":{"muted":true,"percent":68}},"connected":false,"host":{"arch":"armeabi-v7a","ip":"10.0.0.105","mac":"30:39:26:d8:c8:c3","name":"xperiap-alex","os":"Android 5.1.1"},"lastSeen":{"sec":1484375837,"usec":736743},"snapclient":{"name":"Snapclient","protocolVersion":2,"version":"0.10.0"}},{"config":{"latency":2,"name":"Marantz Office","stream":"Wohnzimmer","volume":{"muted":true,"percent":47}},"connected":true,"host":{"arch":"armeabi-v7a","ip":"10.0.0.142","mac":"e0:b9:4d:1d:3f:b6","name":"android-13b65b673dcc71d4","os":"Android 6.0.1"},"lastSeen":{"sec":1484420309,"usec":748464},"snapclient":{"name":"Snapclient","protocolVersion":2,"version":"0.10.0"}},{"config":{"latency":0,"name":"Office","stream":"Wohnzimmer","volume":{"muted":true,"percent":33}},"connected":false,"host":{"arch":"armeabi-v7a","ip":"10.0.0.138","mac":"3c:cf:5b:99:30:64","name":"android-66f49b5f8c6823b7","os":"Android 5.1.1"},"lastSeen":{"sec":1483898839,"usec":448375},"snapclient":{"name":"Snapclient","protocolVersion":2,"version":"0.10.0"}}],"server":{"host":{"arch":"x86_64","ip":"","mac":"","name":"debianmini","os":"Debian GNU/Linux 8.6 (jessie)"},"snapserver":{"controlProtocolVersion":1,"name":"Snapserver","protocolVersion":1,"version":"0.10.0"}},"streams":[{"id":"Wohnzimmer","status":"idle","uri":{"fragment":"","host":"","path":"/tmp/pulsefifo_1","query":{"buffer_ms":"20","codec":"ogg","mode":"read","name":"Wohnzimmer","sampleformat":"48000:16:2"},"raw":"pipe:///tmp/pulsefifo_1?name=Wohnzimmer&sampleformat=48000:16:2&codec=ogg&mode=read","scheme":"pipe"}},{"id":"Badezimmer","status":"idle","uri":{"fragment":"","host":"","path":"/tmp/pulsefifo_2","query":{"buffer_ms":"20","codec":"ogg","mode":"read","name":"Badezimmer","sampleformat":"48000:16:2"},"raw":"pipe:///tmp/pulsefifo_2?name=Badezimmer&sampleformat=48000:16:2&codec=ogg&mode=read","scheme":"pipe"}},{"id":"Buero","status":"idle","uri":{"fragment":"","host":"","path":"/tmp/pulsefifo_3","query":{"buffer_ms":"20","codec":"ogg","mode":"read","name":"Buero","sampleformat":"48000:16:2"},"raw":"pipe:///tmp/pulsefifo_3?name=Buero&sampleformat=48000:16:2&codec=ogg&mode=read","scheme":"pipe"}},{"id":"Schlafzimmer","status":"idle","uri":{"fragment":"","host":"","path":"/tmp/pulsefifo_4","query":{"buffer_ms":"20","codec":"ogg","mode":"read","name":"Schlafzimmer","sampleformat":"48000:16:2"},"raw":"pipe:///tmp/pulsefifo_4?name=Schlafzimmer&sampleformat=48000:16:2&codec=ogg&mode=read","scheme":"pipe"}},{"id":"Kinderzimmer","status":"idle","uri":{"fragment":"","host":"","path":"/tmp/snapfifo_5","query":{"buffer_ms":"20","codec":"ogg","mode":"read","name":"Kinderzimmer","sampleformat":"48000:16:2"},"raw":"pipe:///tmp/snapfifo_5?name=Kinderzimmer&sampleformat=48000:16:2&codec=ogg&mode=read","scheme":"pipe"}},{"id":"T6","status":"idle","uri":{"fragment":"","host":"","path":"/tmp/snapfifo_6","query":{"buffer_ms"
2017.01.14 19:58:30 3: test device opened
2017.01.14 19:58:30 3: :"20","codec":"ogg","mode":"read","name":"T6","sampleformat":"48000:16:2"},"raw":"pipe:///tmp/snapfifo_6?name=T6&sampleformat=48000:16:2&codec=ogg&mode=read","scheme":"pipe"}},{"id":"T4","status":"idle","uri":{"fragment":"","host":"","path":"/tmp/pulsefifo1","query":{"buffer_ms":"20","codec":"ogg","mode":"read","name":"T4","sampleformat":"48000:16:2"},"raw":"pipe:///tmp/pulsefifo1?name=T4&sampleformat=48000:16:2&codec=ogg&mode=read","scheme":"pipe"}}]}}
malformed JSON string, neither array, object, number, string or atom, at character offset 0 (before ":"20","codec":"ogg",...") at ./FHEM/96_Snapcast.pm line 240.
update:
very strange:
wenn ich die 2 letzten zonen auskommentiere lädt es zumindest in jessie mit dem fhemmodul:
SNAPSERVER_OPTS="-d -s pipe:///tmp/pulsefifo_1?name=Wohnzimmer&sampleformat=48000:16:2&codec=ogg&mode=read \
-s pipe:///tmp/pulsefifo_2?name=Badezimmer&sampleformat=48000:16:2&codec=ogg&mode=read \
-s pipe:///tmp/pulsefifo_3?name=Buero&sampleformat=48000:16:2&codec=ogg&mode=read \
-s pipe:///tmp/pulsefifo_4?name=Schlafzimmer&sampleformat=48000:16:2&codec=ogg&mode=read \
-s pipe:///tmp/snapfifo_5?name=Kinderzimmer&sampleformat=48000:16:2&codec=ogg&mode=read"
# -s pipe:///tmp/snapfifo_6?name=T6&sampleformat=48000:16:2&codec=ogg&mode=read "
# -s pipe:///tmp/pulsefifo1?name=T4&sampleformat=48000:16:2&codec=ogg&mode=read"
ich sehe beim besten Willen keinen Unterschied, wieso eine der letzten Zeilen zerstörerisch sein sollte. (nicht dass mir die Terrassenzonen gerade sehr abgehen)
Update:
Es scheint um die Anzahl der Zonen zu gehen (zumindest bei mir) bei der 6. Zone stürzt das mit Modul mit den JSON-Fehlern ab)
Positiv: mit shairport-sync bekommt man eine Zone auf die man vom iMac oder iPhone streamen kann.
: shairport-sync > pipe output > snapserver (funktioniert bei mir nur dann ohne Aussetzer wenn ich beides auf 44100 konfiguriere)
Die hohe Anzahl der Zonen hat wohl dazu geführt, dass die JSON Response so lang wurde, dass die in 2 Schritten eingelesen wurde, und das habe ich nicht erkannt, so kam es zu einem invaliden JSON, den ich (2. Bug) dummerweise nur an einer der zwei Stellen im Modul abgefangen hatte.
Beides habe ich jetzt hoffentlich korrigiert und soeben auf Github eingecheckt. Ich kann bei mir leider gerade keine weiteren Zonen erstellen um es wirklich zu testen.
Das mit PA klingt gut. Ich habe eine lauffähige Version vom Controller ebenfalls auf Github eingecheckt. Damit kann man jetzt schon MPD und Snapcast steuern und auch durch Playlisten durchschalten. Hier mal meine Config, damit du dir eine Vorstellung machen kannst, was man dann alles für Module hat.
define scs.snap Snapcast
define scc.nele Snapcast client scs.snap b827eb9aec84
define scc.merle Snapcast client scs.snap 025009413c29
define scc.kueche Snapcast client scs.snap b827eb9a2ad3
define scc.wohn Snapcast client scs.snap 00aefa4aa3a9
define mac.nele MultiroomAudioController
attr mac.nele mr scc.nele
attr mac.nele soundMapping nele:mpd.nele,merle:mpd.merle,kueche:mpd.kueche,wohn:mpd.wohn
attr mac.nele playlistPattern nele
define mac.merle MultiroomAudioController
attr mac.merle mr scc.merle
attr mac.merle soundMapping nele:mpd.nele,merle:mpd.merle,kueche:mpd.kueche,wohn:mpd.wohn
attr mac.merle playlistPattern merle
define mac.kueche MultiroomAudioController
attr mac.kueche mr scc.kueche
attr mac.kueche soundMapping nele:mpd.nele,merle:mpd.merle,kueche:mpd.kueche,wohn:mpd.wohn
attr mac.kueche playlistPattern wohn
define mac.wohn MultiroomAudioController
attr mac.wohn mr scc.wohn
attr mac.wohn soundMapping nele:mpd.nele,merle:mpd.merle,kueche:mpd.kueche,wohn:mpd.wohn
attr mac.wohn playlistPattern wohn
define mpd.nele MPD 192.168.2.2 6600
attr mpd.nele player mopidy
define mpd.merle MPD 192.168.2.2 6702
attr mpd.merle player mopidy
define mpd.kueche MPD 192.168.2.2 6703
attr mpd.kueche player mopidy
define mpd.wohn MPD 192.168.2.2 6704
attr mpd.wohn player mopidy
Mit dem Attribut soundMapping wird zugeordnet, welcher MPD Player zu welchem Snapcast Client gehört. Abhängig vom Reading "stream", also davon, auf welcher Zone ein Client gerade hört, schaltet sich dann der Controller auf den passenden MPD und updated beim Umschalten alle Readings dementsprechend.
Wenn du Zeit hast, schau doch mal in die Schnittstelle vom Controller. Also die Readings die er bietet, als auch die Kommandos die man per "set" absetzen kann. Ich habe mich an den https://wiki.fhem.de/wiki/DevelopmentGuidelinesAV (https://wiki.fhem.de/wiki/DevelopmentGuidelinesAV) orientiert, was hoffentlich auch der Visualisierung zuträglich ist.
wegen dem pulse sink...ich verzweifle daran, mopidy auf pulse abspielen zu lassen. Angeblich fehlendes MP3 Plugin im gestreamer. Kann aber iwie so einfach nicht sein.
meine config (relevante teile bzw. änderungen zum default)
pulse
system.pa
load-module module-native-protocol-tcp auth-anonymous=1
load-module module-pipe-sink file=/tmp/pulsefifo_1 sink_name=pulsefifo_1
load-module module-pipe-sink file=/tmp/pulsefifo_2 sink_name=pulsefifo_2
load-module module-pipe-sink file=/tmp/pulsefifo_3 sink_name=pulsefifo_3
load-module module-pipe-sink file=/tmp/pulsefifo_4 sink_name=pulsefifo_4
load-module module-pipe-sink file=/tmp/pulsefifo_5 sink_name=pulsefifo_5
pulse
daemon.conf
default-sample-rate = 48000
mopidy
multi_zone1.conf
output = audioresample ! audioconvert ! audio/x-raw,rate=48000,channels=2,format=S16LE ! pulsesink server=127.0.0.1 device=1
und noch die mopidy deps
sysadmin@debianmini:~$ mopidy deps
Executable: /usr/bin/mopidy
Platform: Linux-3.16.0-4-amd64-x86_64-with-debian-8.6
Python: CPython 2.7.9 from /usr/lib/python2.7
Mopidy: 2.1.0 from /usr/lib/python2.7/dist-packages
Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/dist-packages
requests>=2.0: 2.4.3 from /usr/lib/python2.7/dist-packages
tornado>=3.2: 3.2.2 from /usr/lib/python2.7/dist-packages
Mopidy-MusicBox-Webclient: 2.3.0 from /usr/local/lib/python2.7/dist-packages
setuptools: 5.5.1 from /usr/lib/python2.7/dist-packages
Mopidy>=1.1.0: 2.1.0 from /usr/lib/python2.7/dist-packages
Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/dist-packages
requests>=2.0: 2.4.3 from /usr/lib/python2.7/dist-packages
tornado>=3.2: 3.2.2 from /usr/lib/python2.7/dist-packages
Mopidy-Local-SQLite: 1.0.0 from /usr/local/lib/python2.7/dist-packages
uritools>=1.0: 2.0.0 from /usr/local/lib/python2.7/dist-packages
ipaddress: 1.0.17 from /usr/local/lib/python2.7/dist-packages
Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/dist-packages
setuptools: 5.5.1 from /usr/lib/python2.7/dist-packages
Mopidy>=1.1: 2.1.0 from /usr/lib/python2.7/dist-packages
Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/dist-packages
requests>=2.0: 2.4.3 from /usr/lib/python2.7/dist-packages
tornado>=3.2: 3.2.2 from /usr/lib/python2.7/dist-packages
Mopidy-Moped: 0.7.0 from /usr/local/lib/python2.7/dist-packages
setuptools: 5.5.1 from /usr/lib/python2.7/dist-packages
Mopidy>=1.0.0: 2.1.0 from /usr/lib/python2.7/dist-packages
Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/dist-packages
requests>=2.0: 2.4.3 from /usr/lib/python2.7/dist-packages
tornado>=3.2: 3.2.2 from /usr/lib/python2.7/dist-packages
Mopidy-Local-Images: 1.0.0 from /usr/local/lib/python2.7/dist-packages
uritools>=1.0: 2.0.0 from /usr/local/lib/python2.7/dist-packages
ipaddress: 1.0.17 from /usr/local/lib/python2.7/dist-packages
Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/dist-packages
setuptools: 5.5.1 from /usr/lib/python2.7/dist-packages
Mopidy>=1.1: 2.1.0 from /usr/lib/python2.7/dist-packages
Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/dist-packages
requests>=2.0: 2.4.3 from /usr/lib/python2.7/dist-packages
tornado>=3.2: 3.2.2 from /usr/lib/python2.7/dist-packages
Mopidy-Podcast: 2.0.1 from /usr/local/lib/python2.7/dist-packages
Mopidy>=1.1.1: 2.1.0 from /usr/lib/python2.7/dist-packages
Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/dist-packages
requests>=2.0: 2.4.3 from /usr/lib/python2.7/dist-packages
tornado>=3.2: 3.2.2 from /usr/lib/python2.7/dist-packages
uritools>=1.0: 2.0.0 from /usr/local/lib/python2.7/dist-packages
ipaddress: 1.0.17 from /usr/local/lib/python2.7/dist-packages
setuptools: 5.5.1 from /usr/lib/python2.7/dist-packages
Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/dist-packages
cachetools>=1.0: 2.0.0 from /usr/local/lib/python2.7/dist-packages
Mopidy-Spotify: 3.0.0 from /usr/lib/python2.7/dist-packages
Mopidy>=2.0: 2.1.0 from /usr/lib/python2.7/dist-packages
Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/dist-packages
requests>=2.0: 2.4.3 from /usr/lib/python2.7/dist-packages
tornado>=3.2: 3.2.2 from /usr/lib/python2.7/dist-packages
Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/dist-packages
pyspotify>=2.0.5: 2.0.5 from /usr/lib/python2.7/dist-packages
cffi>=1.0.0: 1.1.2 from /usr/lib/python2.7/dist-packages
pycparser: 2.10 from /usr/lib/python2.7/dist-packages
requests>=2.0: 2.4.3 from /usr/lib/python2.7/dist-packages
GStreamer: 1.4.4.0 from /usr/lib/python2.7/dist-packages/gi
Detailed information:
Python wrapper: python-gi 3.14.0
Relevant elements:
Found:
uridecodebin
souphttpsrc
appsrc
alsasink
osssink
oss4sink
pulsesink
id3demux
id3v2mux
lamemp3enc
mad
mpegaudioparse
vorbisdec
vorbisenc
vorbisparse
oggdemux
oggmux
oggparse
flacdec
flacparse
shout2send
Not found:
flump3dec
Danke. Das passt alles so bei mir. Es ist ein anderes Problem, da ist irgendwas faul mit meiner Installation. Aber egal, das mach ich später.
Für die ganze Konfig und Doku werd ich wohl demnächst eine WIKI Seite erstellen.
Hi, habe gerade auf meinem blanken Test-FHEM das Snapcast Modul-Update ausprobiert. FHEM stürzt jetzt zwar nicht mehr ab, aber das Modul meldet trotzdem einen JSON Fehler
2017-01-16 20:38:48 Snapcast snapcast lastError: Invalid JSON: {"id":37,"jsonrpc":"2.0","result":{"clients":[{"config":{"latency":0,"name":"Mi5 Test","stream":"Buero","volume":{"muted":false,"percent":44}},"connected":false,"host":{"arch":"arm64-v8a","ip":"10.0.0.196","mac":"78:02:f8:21:77:7a","name":"MI5-AlexPhone","os":"Android 6.0"},"lastSeen":{"sec":1484470481,"usec":769346},"snapclient":{"name":"Snapclient","protocolVersion":2,"version":"0.10.0"}},{"config":{"latency":0,"name":"Radio Kitchen","stream":"Wohnzimmer","volume":{"muted":false,"percent":100}},"connected":true,"host":{"arch":"armeabi-v7a","ip":"10.0.0.189","mac":"a0:f4:59:c7:c3:95","name":"android-740a459bf24dd0a","os":"Android 4.2.2"},"lastSeen":{"sec":1484595527,"usec":326142},"snapclient":{"name":"Snapclient","protocolVersion":2,"version":"0.10.0"}},{"config":{"latency":0,"name":"Yamaha Wohnzimmer","stream":"Wohnzimmer","volume":{"muted":false,"percent":67}},"connected":true,"host":{"arch":"armeabi-v7a","ip":"10.0.0.117","mac":"08:61:51:20:54:37","name":"android-58377744637334b8","os":"Android 4.4.2"},"lastSeen":{"sec":1484595527,"usec":418044},"snapclient":{"name":"Snapclient","protocolVersion":2,"version":"0.10.0"}},{"config":{"latency":22,"name":"Radio Badezimmer","stream":"Wohnzimmer","volume":{"muted":true,"percent":68}},"connected":true,"host":{"arch":"armeabi-v7a","ip":"10.0.0.105","mac":"30:39:26:d8:c8:c3","name":"xperiap-alex","os":"Android 5.1.1"},"lastSeen":{"sec":1484595528,"usec":880379},"snapclient":{"name":"Snapclient","protocolVersion":2,"version":"0.10.0"}},{"config":{"latency":2,"name":"Marantz Office","stream":"Buero","volume":{"muted":false,"percent":93}},"connected":true,"host":{"arch":"armeabi-v7a","ip":"10.0.0.142","mac":"e0:b9:4d:1d:3f:b6","name":"android-13b65b673dcc71d4","os":"Android 6.0.1"},"lastSeen":{"sec":1484475525,"usec":200463},"snapclient":{"name":"Snapclient","protocolVersion":2,"version":"0.10.0"}},{"config":{"latency":0,"name":"Office","stream":"Wohnzimmer","volume":{"muted":true,"percent":33}},"connected":false,"host":{"arch":"armeabi-v7a","ip":"10.0.0.138","mac":"3c:cf:5b:99:30:64","name":"android-66f49b5f8c6823b7","os":"Android 5.1.1"},"lastSeen":{"sec":1483898839,"usec":448375},"snapclient":{"name":"Snapclient","protocolVersion":2,"version":"0.10.0"}}],"server":{"host":{"arch":"x86_64","ip":"","mac":"","name":"debianmini","os":"Debian GNU/Linux 8.6 (jessie)"},"snapserver":{"controlProtocolVersion":1,"name":"Snapserver","protocolVersion":1,"version":"0.10.0"}},"streams":[{"id":"Wohnzimmer","status":"idle","uri":{"fragment":"","host":"","path":"/tmp/pulsefifo_1","query":{"buffer_ms":"20","codec":"ogg","mode":"read","name":"Wohnzimmer","sampleformat":"48000:16:2"},"raw":"pipe:///tmp/pulsefifo_1?name=Wohnzimmer&sampleformat=48000:16:2&codec=ogg&mode=read","scheme":"pipe"}},{"id":"Badezimmer","status":"idle","uri":{"fragment":"","host":"","path":"/tmp/pulsefifo_2","query":{"buffer_ms":"20","codec":"ogg","mode":"read","name":"Badezimmer","sampleformat":"48000:16:2"},"raw":"pipe:///tmp/pulsefifo_2?name=Badezimmer&sampleformat=48000:16:2&codec=ogg&mode=read","scheme":"pipe"}},{"id":"Buero","status":"idle","uri":{"fragment":"","host":"","path":"/tmp/pulsefifo_3","query":{"buffer_ms":"20","codec":"ogg","mode":"read","name":"Buero","sampleformat":"48000:16:2"},"raw":"pipe:///tmp/pulsefifo_3?name=Buero&sampleformat=48000:16:2&codec=ogg&mode=read","scheme":"pipe"}},{"id":"Schlafzimmer","status":"idle","uri":{"fragment":"","host":"","path":"/tmp/pulsefifo_4","query":{"buffer_ms":"20","codec":"ogg","mode":"read","name":"Schlafzimmer","sampleformat":"48000:16:2"},"raw":"pipe:///tmp/pulsefifo_4?name=Schlafzimmer&sampleformat=48000:16:2&codec=ogg&mode=read","scheme":"pipe"}},{"id":"Kinderzimmer","status":"idle","uri":{"fragment":"","host":"","path":"/tmp/pulsefifo_5","query":{"buffer_ms":"20","codec":"ogg","mode":"read","name":"Kinderzimmer","sampleformat":"48000:16:2"},"raw":"pipe:///tmp/pulsefifo_5?name=Kinderzimmer&sampleformat=48000:16:2&codec=ogg&mode=read","scheme":"pipe"}},{"id":"Airport","status":"idle","uri":{"fragment":"","host":"","path":"/tmp/shairport_1","query":{"buffer_ms":"20
2017-01-16 20:38:48 Snapcast snapcast lastError: Invalid JSON: ","codec":"ogg","mode":"read","name":"Airport","sampleformat":"44100:16:2"},"raw":"pipe:///tmp/shairport_1?name=Airport&sampleformat=44100:16:2&codec=ogg&mode=read","scheme":"pipe"}}]}}
danke für das Feedback. Ich habe gestern noch gebastelt und den jetzigen Fehler auch bemerkt. Ich will das bis heute Abend endgültig gelöst haben.
Wenn du eine Wiki-Seite dazu machst würde ich mich anbieten den Part mit der Mopidy + Pulse + Snapcast im Wiki einzuarbeiten.
gerne, behalte ich im Auge!
@drdownload: Dein System müsste jetzt auch mit 100 Streams laufen :)
Sehr gut, danke, dann kann ich endlich den blauen Flügel meines Schlosses auch integrieren ;)
whoohooo mit dem letzten update geht das plugin auch auf meinem hauptfhem auf wheezy!
freut mich zu hören. Kann Bugs nicht ausschließen aber ich habs zumindest rauf und runter getestet.
Was wird denn in Zukunft die Aufgabe vom Multiroom-Controller sein im Vergleich zu den Snapcast-Clients?
Er ist eine Abstraktionsebene und kombiniert die Steuerung von:
- Snapcast Client Modul
- MPD Modul
- TTS Ansagen
- Steuerung über Fernbedienung mit Nummerneingabe und anderen Gimmicks
Er reicht einerseits die Schnittstelle vom Snapcast und MPD Modul in einem einzigen Modul kombiniert weiter. Er ist so geschrieben, dass es nicht zwingend Snapcast und MPD sein muss sondern man auch andere Backends nehmen könnte. Wechselt man mit dem Controller den Stream eines Snapcast-Clients, dann schwenken die MPD Readings und die Kontrolle auch auf das MPD des entsprechenden Streams um. Ich steuere also automatisch immer denjenigen MPD, dem ich gerade zuhöre. So hatte ich mir erhofft, dass man das sehr gut auch in die Visualisierung einbauen kann.
Man kann direkt ein TTS Modul anbinden, hier nutze ich das bestehende Text to Speech Modul. Dadurch kann man, wenn man es aktiviert, Rückmeldung bei einer Displaylosen bedienung erhalten. Im TTS Modul lässt sich ja nicht nur Sprache, sondern auch festgelegte Sounds hinterlegen.
Es sind weiterhin Funktionen direkt implementiert, die über die Funktionalität von MPD / Snapcast hinaus gehen und da auch nicht unbedingt etwas verloren haben. Einige neue Sachen werde ich direkt bei MPD einbauen, hab mich dazu schon im MPD Thread geäußert.
Ich bin mit dem Modul schon sehr weit, ich rechne Ende nächster Woche mit einer vollständig brauchbaren Version. Die Schnittstelle ist schon definiert und die Readings / sets stehen soweit fest. Gerne nehme ich noch Vorschläge entgegen. Wie gesagt habe ich mich an den AV Guidelines ausgerichtet. Ich habe in anderen Threads gesehen, dass es schon sehr gute Umsetzungen für TabletUI und Smartvisu gibt. Mit wenigen Anpassungen müsste man die direkt verwenden können.
Habe eine WIKI-Seite erstellt, auf der natürlich noch viel viel fehlt. Das Schaubild sollte schonmal ungefähr zeigen, wie das so gedacht ist.
Das Modul selbst ist fertig und funktionsfähig mit fast allen Features. Ich muss aber noch komplett die Commandref schreiben bevor ich es veröffentlichen kann. Das wird noch im Januar geschehen (da ich im Februar dann nur noch wenig Zeit habe)
https://wiki.fhem.de/wiki/OpenMultiroom
Ich schließe den Thread, ab jetzt gehts bei https://forum.fhem.de/index.php/topic,65785.0.html weiter.
Danke an alle, die sich beteiligt haben!