Lost in options - Yamaha, DLNA und MPD: Wie zusammenpuzzeln?

[Beta-User]

Hallo zusammen,

vielleicht hat ja jemand eine Idee, wie ich am schnellsten auf den aktuellen bzw. "optimalen" Stand komme.

Gegeben sind derzeit:
- ein Yamaha-Receiver, zwei Zonen (Wohnzimmer, Esszimmer), eingebunden seit langem mit YAMAHA_AVR (x2);
- ein MPD-Service (vor kurzem aktualisiert auf 0.23.1), eine Instanz, auf einem anderen Rechner, eingebunden in FHEM via MPD-Modul;
- der andere Rechner ist via HDMI mit dem Receiver verbunden. Dadurch bedingt kann man "MPD-Musik" an zone2 nur ausgeben, wenn "mainsync" aktiv ist. MPD läuft in der user-Sphäre, damit das mit der direkten Sound-Ausgabe klappt.

Letzteres (HDMI-Ausgabe) hat mich bisher nur mäßig gestört, u.a., weil TTS-Ausgaben bisher nicht auf dem "Speiseplan" standen und die Musik-Steuerung via Handy (MALP) sowieso komfortabler (bzw. mehr oder weniger die einzige Möglichkeit) war.
Im Hintergrund läuft zwar auch schon ewig ein minidnla-Server, der auch auf die ganze Sammlung zugreift, von daher ist es über "Server" in der Musiccast-App auch möglich, unabhängig von mainzone irgendwas abzuspielen, aber das macht (mir) keinen Spaß...

Nun denn, stellt sich die Frage, wie man das ganze flexibler macht und ggf. gleich so ausbaut, dass noch weitere Geräte eingebunden werden können.

1.
Über den "MPD-Pfad" bin ich auf https://wiki.fhem.de/wiki/OpenMultiroom gestoßen. Klingt interessant, ist aber aktuell nicht gepflegt, als "Multiroom-System" wird Snapcast vorausgesetzt, das auch ohne Maintainer ist. Nun ja, jedenfalls müßte es eigentlich möglich sein, "einfach nur" einen oder mehrere Streams - entweder mit Hilfe virtueller sound- (pulseaudio?) -Ausgänge aus MPD (?) oder mit sowas wie https://wiki.ubuntuusers.de/pulseaudio-dlna/ (?) - zu generieren, auf die dann die beiden YAMAHA_AVR-Instanzen über das Netzwerk zugreifen.

Vorteil: Über RHASSPY _könnte_ ich relativ flexible Kommandos auf die Sammlung loslassen (das bräuchte nur ziemlich viel Trainingszeit...).
Falls sich das als zielführend erweist, würde ich ggf. das/die Modul/e OpenMultiroom und Snapcast übernehmen (soweit von mir benötigt).

2.
Es gibt auch YAMAHA_MC als Modul, aber da bin ich nach einem Blick in den Code eher skeptisch, ob ich das gut finde, und rauszufinden, wie das ggf. zu bedienen ist und welche Vorteile es effektiv gg. YAMAHA_AVR hat, erscheint mir auch nicht unbedingt intuitiv...

3.
Zu guter Letzt (?) gibt es dann noch das generische SSDP-Modul, das grade "in der Mache" ist - https://forum.fhem.de/index.php/topic,114457.0.html. Klingt auch interessant, aber irgendwie fehlt mir auch da grade der Durchblick, was denn da eigentlich grade der letzte Stand ist und wo man sich einklinken müßte...
(Und wie das dann ggf. zu meinen Bedien-Erwartungen paßt - sowas wie "spiel 20 Titel von Gary Moore" als Sprachanweisung wäre (bzw. ist!) schon cool ).

Vielleicht kann mir ja jemand grob die Richtung weisen, ohne dass ich nochmal "das ganze Internet" lesen muss und gefühlt 1000 Sachen austesten, die dann am Ende nicht zusammenpassen? Oder hat eine bessere Variante?

Grüße,

Beta-User

[enno]

Moin Beta-User,

ich häng mich hier mal mit an.

Nutze YAMAHA_AVR auf HTR-4068 und YAMAHA_MC mit zwei WX010. Sprachausgabe läuft auf einem WX010 mit DLNA nach der Anleitung von Leugi (https://forum.fhem.de/index.php/topic,98383.0.html). Leider nicht sehr zuverlässig.

Wenn hier was gutes zusammengepuzzelt wird, ich bin dabei.

Gruss
  Enno

[Beta-User]

Moin enno,

dann mal "Willkommen and Bord" hier.

Klingt jedenfalls nicht danach, als wäre meine Skepsis gg. dem Weg 2 (YAMAHA_MC-Modul) komplett unbegründet, wenn du da auch eher weg von willst... (oder habe ich das falsch verstanden?)

Meine nächsten Schritte werden dann sein (erst mal ohne FHEM):
- Installation von Pulsaudio (Server) und Snapcast-Server auf meinem FHEM-Server (?) gem. Anleitung von https://wiki.fhem.de/wiki/OpenMultiroom;
- Dann bekommt der zwei neue "Ausgänge" über pulseaudio-module-raop (Airtunes-Schnittstelle), und dazu passend zwei Snapcast-Clients?
- Der MPD bekommt noch einen "Ausgang" des Typs "pulse" (Linkliste dazu vorläufig: https://wiki.fhem.de/wiki/OpenMultiroom#Mopidy_Konfiguration, https://wiki.debianforum.de/MPD_als_Systemdienst_mit_ALSA_und_Pulseaudio#Konfiguration_von_MPD https://wiki.archlinux.org/title/Music_Player_Daemon/Tips_and_tricks#PulseAudio

Vermutlich alles ziemlich verwirrend, aber in https://forum.manjaro.org/t/tutorial-how-to-stream-audio-from-your-pc-to-any-device/71047 habe ich folgendes gefunden, was die ganze "normale" Kette eigentlich einleuchtend beschreibt:

The goal is to build the following chain:
audio player software → snapfifo → snapserver → network → snapclient → alsa

Übersetzt in mein setup würde dies also in etwa so aussehen:

(audio player software/MPD → network)  → snapfifo → snapserver → (network/localhost) → snapclient → raop-sink → YAMAHA-Zone (via network)

[enno]

Pulseaudio fällt bei mir aus, da ich MPD im Keller laufen habe und zu den Geräten mit ICECAST streame. Ich lese noch bei der Entwicklung von KölnSolar (https://forum.fhem.de/index.php/topic,118837.0.html) mit. Meine Hoffnung ist DLNA stabil zum Laufen zu bekommen. Von der Lösung einen weiteren Raspi mit Soundkarte an die Stereoanlage zu bringen bin ich gerade weg.

Das YAMAHA_MC-Modul  nutze ich recht intensiv, da ich dort die Möglichkeit habe die Geräte miteinander zu verlinken (mc_link). Mir fehlt halt nur die Möglichkeit schnell und stabil mal tts auf einem der Geräte auszugeben.

Gruss
  Enno

[Beta-User]

Pulseaudio fällt bei mir aus, da ich MPD im Keller laufen habe
[...]
Von der Lösung einen weiteren Raspi mit Soundkarte an die Stereoanlage zu bringen bin ich gerade weg.

Hmm, wenn ich zum einen https://wiki.debianforum.de/MPD_als_Systemdienst_mit_ALSA_und_Pulseaudio#Konfiguration_von_MPD und zum anderen den prinzipiellen Ansatz in https://wiki.fhem.de/wiki/OpenMultiroom richtig verstanden habe, _kann_ man den MPD ohne weiteres "irgendwo" im Netz haben und an einer völlig anderen Stelle dann die Soundausgabe machen.

Der Nachteil der Skizze in/zu OpenMultiroom ist "nur", dass dort in der Tat für die Audio-Ausgabe eigentlich das Modell "Linux-Soundkarte+irgendeine Verstärkerhardware" als exklusiv dargestellt ist. Meine Idee wäre, den Ausgabeteil eben um die Option "Airplay" zu erweitern, also die (afaik weit verbreitete Apple-) Alternative zum Yamaha-Musiccast-Protokoll. Damit würde für deine Hardware eben gerade kein Pi+Soundkarte benötigt, und man könnte auch beliebige "fremde" Hardware darüber ansprechen.

und zu den Geräten mit ICECAST streame.

Auch ein interessantes Stichwort, über das ich schon auch immer mal wieder gestolpert bin. Kommt mal auf meine "ist vielleicht eine Alternative"-Liste. Wenn das mit der Soundvernetzung klappt, ziehe ich vielleicht die Musik-Daten auf den FHEM-Server um und betreibe ein paar MPD-Instanzen, um was ähnliches zu erreichen. Der Vorteil vom MPD liegt für mich darin, dass ich zwischenzeitlich weiß, wie man den "flexibel" und per regexp "füttert", so dass auch Spracheingabe klappt. Daher will ich eher daran mal festhalten.

Ich lese noch bei der Entwicklung von KölnSolar (https://forum.fhem.de/index.php/topic,118837.0.html) mit. Meine Hoffnung ist DLNA stabil zum Laufen zu bekommen.

OK, dann scheint das der aktuelle Thread zum Thema DLNA zu sein (und der Status eher noch verbesserungsfähig).

Das YAMAHA_MC-Modul  nutze ich recht intensiv, da ich dort die Möglichkeit habe die Geräte miteinander zu verlinken (mc_link). Mir fehlt halt nur die Möglichkeit schnell und stabil mal tts auf einem der Geräte auszugeben.

Das mit dem Verlinken ist ein wichtiger Aspekt. Da ich im Moment nur eine Hardware habe, reicht mit die "party mode"-Option aus dem "normalen" AVR-Modul, aber für die mittlere Perspektive wäre natürlich interessant, das auch (mindestens) gleichwertig hinzubekommen. Mindestens meint: bei "normalen MC-Links" meine ich etwas Zeitversatz zu haben, der beim party mode nicht zu hören/besser ist. Daher nutze ich halt eher diese Funktion...
Was "gleichwertig" angeht, kann es sein, dass die Apfel-Methode genau dasselbe bewirkt (aber eben herstellerübergreifend), hilfsweise könnte man über die Integration der erforderlichen MC-Optionen sprechen. Mir gefallen halt "sleep"-Anweisungen in FHEM-Modulen nicht, das MC-Modul wirkt auf mich einfach nicht ausgereift. Kann aber sein, dass ich damit komplett daneben liege.

EDIT:
Falls hier jemand mitliest, der das Modul OpenMultiroom erfolgreich im Einsatz hat - bitte melden. Ich hätte eine erst mal nur nach meinen Vorstellungen gesäuberte Version ausgetüftelt, von der ich noch nicht weiß, dass noch alles funktioniert, was vorher auch funktioniert hatte...

[Wernieman]

mpd kann verschiedene audio-Quellen verarbeiten, eben nicht nur die lokale soundkarte.

Hatte selber auch schonmal in die Richtung gespielt, bin aber "damals" vor c.a. ?3? Jahren daran gescheitert. Bin aber auch eher bei pulsaudio hängengeblieben.

Muß jetzt aber auch gestehen, das ich nicht alle Eure Beiträge in der Tiefe gelesen habe, muß/kann ich erst heute Abend ...

[schwatter]

Tag,
Mh ich nutze schon 4 Jahre upmpdcli aufm Raspi mit Fhem und MPD. Vorrangig um per Handy extern mit AirAudio Musik zu hören. Das ganze sogar noch mit dem internen Bluetooth an einem Speaker.

Jetzt könnte man an sich selbst bzw upmpdcli Audio oder TTS schicken. Sowie auch an einem anderen Clienten im Netzwerk mit MPD und upmpdcli.

Aufpassen muss ich nur wenn TTS von Fhem dazwischen haut. Dann klingt upmpdcli kaputt.
Neustart erforderlich. Da muss ich nochmal schaue wie ich den Dienst für TTS kurz unterbreche.
Hab ich das Wirrwarr verstanden ? Denke halb und halb.

https://www.lesbonscomptes.com/upmpdcli/

Gruß schwatter

[Beta-User]

  Das Thema scheint allgemein interessant zu sein, die rege Beteiligung hier deute ich jedenfalls mal so.

Hab ich das Wirrwarr verstanden ? Denke halb und halb.

Du hast das vermutlich jedenfalls besser als ich durchschaut, und upmpdcli nehme ich auch mal auf meine "für später"-Liste . Ist vermutlich "nur halb", was ich suche, das scheint seine Stärken eher auf der Bedienerseite zu haben und es zu erleichtern, "schlanke" MPD-Instanzen unmittelbar vor dem Abspielgerät zu haben?
Der Satz "and also brings new functions such as synchronized multiroom (Songcast), and access to streaming services." irritiert mich allerdings etwas. Nutzt du den Teil?

Das scheint ja dieselbe Idee zu sein, die hinter Snapcast steckt, also sowas wie eine zentrale Verwaltungsinstanz für alle Arten von Sound-Ein- und Ausgängen...

Das direkt auf Pulseaudio mit Snapcast aufzubauen, scheint mir im Moment stärker entgegenzukommen, das kommt mir wie der direktere Weg vor (soweit ich mich jetzt eingelesen habe, war Pulseaudio via Netzwerk vor 11.0 eher "grottig", und man brauchte eine Menge würgarounds, was vermutlich auch der tiefere Grund ist, warum mein MPD im Usermode läuft...). Mal sehen, vermutlich muss ich einfach mal ein paar Tests machen. Wird etwas dauern...

[schwatter]

Ist vermutlich "nur halb", was ich suche, das scheint seine Stärken eher auf der Bedienerseite zu haben und es zu erleichtern, "schlanke" MPD-Instanzen unmittelbar vor dem Abspielgerät zu haben?
Der Satz "and also brings new functions such as synchronized multiroom (Songcast), and access to streaming services." irritiert mich allerdings etwas. Nutzt du den Teil?

Ja, schlank. Aber irgendwie auch nicht. Ich benutze ihn rein als Render. Wobei Multiroom schon toll wäre. Aber das kann er wohl wirklich nur mit Songcast.

Die Doku finde ich auch sehr Dev-Lastig... fühl sich nicht sehr Enduserfreundlich an.

Gruß schwatter

[Beta-User]

So, kleines update - es gibt ein paar Sachen, die funktionieren "prinzipiell", und andere, bei denen ich noch etwas am rumstolpern bin...

Was geht:
1. Linux-Laptop => Sound-Output an der Airplay-Schnittstelle des Yamaha (beide Zonen haben nur eine gemeinsame?)
2. MPD@FHEM-Server => Snapcast-Server@FHEM-Server  (default) => Snapcast-Client@Wohnzimmer-Linux-Box => Sound-Output via HDMI am Yamaha
3. (anscheinend) Anlegen der "pipe-sink"-pulseaudio-Schnittstellen am FHEM-Server (Server mode) wie in https://wiki.fhem.de/wiki/OpenMultiroom#Pulseaudio_Konfiguration beschrieben
4. (anscheinend) Anlegen der "raop-sink"-pulseaudio-Schnittstelle am FHEM-Server (Server mode) (die habe ich vorsichtshalber dann noch in eine "combine-sink" gedoppelt in der Hoffnung, dass die dann über Snapcast/OpenMultiroom irgendwie auswählbar wäre; Fehlanzeige bisher..).

Was (noch) nicht:
a. FHEM-Server  => Sound-Output an der Airplay-Schnittstelle des Yamaha (beide Zonen haben nur eine gemeinsame?) aus 4. Es ist zwar so, dass anscheinend eine Verbindung aufgebaut wird, wenn man die zum default sink erklärt und dann darüber was abspielt, effektiv hatte ich darüber aber bisher keinen hörbaren Sound (wohl aber eine Art "da kommt was"-Anzeige in der Yamaha-App*!).
b. Nutzung der "pipe-sink"-Schnittstellen durch den Snapcast-Server. Da scheint der im Wiki beschriebene Aufruf nicht zu klappen, vermutlich hat sich da was an der Syntax getan bzw. der Verteilung der erforderlichen Abgaben auf die diversen Konfigurationsdateien von Snapcast-Server.

Snapcast-client läßt sich jedenfalls auch nicht mit dem "-d" Parameter starten

Ad 2. noch:
Auf der Wohnzimmer-Box läuft ein Liux mit GUI. Um da den Sound von Seitens Snapcast-Client in den (in der User-Sphäre) laufenden Pulseaudio-Server einzuschleusen, mußte module-http-protocol-tcp in die default.pa aufgenommen und localhost zugelassen werden.


Sonstiges noch:
- Die Snapcast-App (von badaix) wollte sich erst dann mit dem Server verbinden, nachdem IPV6 aktiviert war. Jetzt ist aber der Client auf dem FHEM-Server doppelt vorhanden (ein 2. Mal mit einer 0-er ID, wird auch im Snapcast-Modul so angezeigt).

- Das ist alles etwas frickelig und anscheinend ist die Anleitung im Wiki zu OpenMultiroom mind. in Teilen veraltet. Wenn ich dann irgendwann hoffentlich den Durchblick habe, gibt's ein update...

- Der FHEM-Server kennt bisher kein Alsa. Kann sein, dass das der Grund ist, warum * nur "so halb" funktioniert, also anscheinend eine Verbindung da ist, aber nichts zu hören...

Falls jemand sonst noch zielführende Hinweise hat: Her damit. Ansonsten mache ich erst mal auf dem Pulseaudio-Weg weiter...

[rcmcronny]

Hi,

also ich habe aktuell ein Setup wie folgt:

3 PIs mit jeweils einem Verstärker Hat / bzw DAC mit Boxen dran. Darauf die Snapcast Clients jeweils mit Raspbian Standard. Küche,Bad,Schlafzimmer
Der Server ist eine KVM VM mit Ubuntu 22.04 und MPD (mopidy hatte ich mal aber gab mehr Probleme leider), dieser hat die Music Sammlung per Netzwerkshare eingebunden.

Fhem nutzt per Pulseaudio Remote diesen auch als TTS Endpunkt und Ausgaben überschreiben quasi die Musik (bzw verringern die Lautstärke damit es hört).
Der Wecker nutzt DOIF um per FHEM MPD Client  den Status zu sichern und dann eine Wecker Playlist zu aktivieren, die dann beim Ende automatisch wieder zur gespeicherten Playlist zurückgeändert wird (Enweder wenn Zeit X oder wenn ich das Haus verlasse automatisch).

Das FHEM Snapcast Modul nutze ich bisher eher als Informationsstatus. Das hatte in der Vergangenheit so Problemchen, da muss ich noch etwas die Steuerung anpassen.


Pulseaudio ist aber der Weg to go, wenns läuft ... wenn ich was beitragen kann, gern.

Ronny

[Wernieman]

Also vom MPD über pulseaudio zu snapcast un dann streaming zu den 3 Clients?

[Beta-User]

Also vom MPD über pulseaudio zu snapcast un dann streaming zu den 3 Clients?

So müßte es nach meinem Verständnis sein.

wenn ich was beitragen kann, gern.

Vorab mal Danke für's Melden hier!
Damit scheinen wir zum einen ein funktionierendes setup zu haben auf einem aktuellen OS - und das ganze noch mit MPD statt Mopidity (wie im FHEM-Wiki beschrieben). Sehr schön (weil für mich leichter anzupassen). Leider ohne direkte Soundausgabe* auf dem Server, aber das wäre eher schon "Kür".

Hätte da gleich mal ein paar Detailfragen:

Der Server ist eine KVM VM mit Ubuntu 22.04 und MPD

Eine oder mehrere MPD-Instanzen? Wenn mehrere: Als "Slave" konfiguriert (zwecks gemeinsamer Nutzung der internen Datenbank)?
Wie sieht exemplarisch die Audio-Ausgabe an den "pipe"-pulseaudio-sink** aus? In welchen Modi laufen pulseaudio und snapserver auf dem FHEM-Server (daemon modus oder "normal")?
pulseaudio müßte vermutlich eine Netzwerkschnittstelle aktiviert haben, damit beliebige User darauf zugreifen können? Also so eine Zeile in system.pa vorhanden sein:

Code Auswählen Erweitern

load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1

**Bzgl. des audio-outputs wäre ich auf sowas in der Art hier gekommen

Code Auswählen Erweitern

audio_output {
    type                "pulse"
    name                "Pulse wohn"
    server             "127.0.0.1"        # optional
    sink                "wohn"      # optional
    stream-properties   "props,media.role=music"
}
Irgendwas in der Richtung hatte ich schon versucht, aber irgendwas "klemmte" (ergo: muss mir die Zeit nehmen, das alles in Ruhe nochmal durchzugehen).

Fhem nutzt per Pulseaudio Remote diesen auch als TTS Endpunkt und Ausgaben überschreiben quasi die Musik (bzw verringern die Lautstärke damit es hört).

Also wird nicht wie im FHEM-Wiki zu OpenMultiroom beschrieben der TTS-Sound bereits auf der Server-Seite dazugemischt?
Die dortigen Konfigurationen ("define tts.wohn Text2Speech pulsewohn") sehen für mich auch komisch aus, nach einer der wenigen Fundstellen dazu wäre ich eher auf sowas hier gekommen (unterstellt, als Standardplayer wird mplayer verwendet):

Code Auswählen Erweitern

define tts.wohn Text2Speech pulse::wohn

Damit wären wir dann auch bei der Frage, wie man bestimmte sinks auf dem FHEM-Server selbst mit snapclient direkt auswählt. Dazu hatte ich folgendes Beispiel gefunden:

Code Auswählen Erweitern

SNAPCLIENT_OPTS="--player pulse --soundcard 0 --sampleformat 96000:24:* --mixer hardware --host 127.0.0.1 --logfilter *:notice"
Im Ergebnis müßte sich damit also eigentlich jeder beliebige sink geziehlt auswählen lassen, was dann auch das "Problemchen" mit dem Airplay-sink lösen würde und z.B. die Option eröffnen, (getrennt) noch z.B. auch BT- und/oder analoge Lautsprecher anzusteuern (per weiterer client-Instanzen).

Das FHEM Snapcast Modul nutze ich bisher eher als Informationsstatus. Das hatte in der Vergangenheit so Problemchen, da muss ich noch etwas die Steuerung anpassen.

Die "Problemchen" würden mich natürlich jetzt auch interessieren, aber das können wir dann ggf. an anderere Stelle vertiefen .

Nachtrag noch - ein m.E. sehr instruktiver Beitrag zur Analyse von pulseaudio auf der Kommandozeile:
https://shallowsky.com/linux/pulseaudio-command-line.html

[adn77]

Sorry, falls der Eindruck entsteht, das folgende wäre Off-Topic.

Ich habe das Thema Multiroom-Audio mit Linux seit über 20 Jahren verfolgt.
Mein letzer Stand war hier: https://blog.loetzimmer.de/2017/01/homeautomation-and-multi-room-audio.html
Per combine verbundene Sinks leierten bei mir immer. RAOP auf Pioneer/Yamaha benötigte das damals nur als Alpha verfügbare RAOP2 Protokoll in Pulseaudio.

Aus dem Blog gibt es einen interssanten Link auf https://www.lesbonscomptes.com/upmpdcli/ , was per Songcast auch synchronisiertes Audio ermöglicht.

Inzwischen benutze ich allerdings Amazon Echos in allen Varianten (auch z.B. per Line-in an meinem Receiver). Und steure diese über die Shell (oder per Fhem Modul). Mpd streams kommen per lokaler Icecast-TuneIn-DNS Umleitung.

Die Lösung ist deutlich stabiler als alle Soundserver, die ich je hatte Und sie skaliert viel besser - aber so häufig kommt wohl kein weiterer Raum hinzu   

[Beta-User]

Sorry, falls der Eindruck entsteht, das folgende wäre Off-Topic.

? Wieso?
Imo ist das ziemlich on topic, weil letztlich geht es doch darum, wie man am einfachsten (optimalerweise mit der eben nun mal "zufällig" vorhandenen Hardware) zu einem technisch und v.a. akkustisch überzeugenden Ergebnis kommt...

Von daher sind solche Erfahrungswerte wie diese hier wichtig!

Die Lösung ist deutlich stabiler als alle Soundserver, die ich je hatte Und sie skaliert viel besser - aber so häufig kommt wohl kein weiterer Raum hinzu   

Ausbaupläne hatte ich eigentlich nicht, aber erfahrungsgemäß kommt der Appetit manchmal beim Essen .

Per combine verbundene Sinks leierten bei mir immer.

...da bin ich ja mal gespannt, ob sich zwischenzeitlich was getan hat. Ist aber zum einen nicht mein Hauptanwendungsfall, und zum anderen will ich "eigentlich" bei meinem "Hauptgerät" - wenn möglich - die internen Optionen direkt und vorrangig nutzen. Ein erster Schritt in die Richtung wird sein, die Lautstärkeregelung beim OpenMultiroom-Modul ggf. so zu modifizieren, dass möglichst der angelieferte Sound voll aufgedreht ist und der Rest dann die Hardware erledigt. Wird tendenziell ein längerer Weg, aber die ersten Readings in die Richtung sind da...

RAOP auf Pioneer/Yamaha benötigte das damals nur als Alpha verfügbare RAOP2 Protokoll in Pulseaudio.

Irgendwie liest sich die Doku immer noch, als wäre das "alpha". Effektiv war der ausgegebene Klang aber bei meinen bisherigen Tests ok (wenn was kam), und der dafür erforderliche sink ist auch zuverlässig da. Vorteil wäre, dass die Lautstärkeregelung anscheinend direkt an die Hardware geht.

Aus dem Blog gibt es einen interssanten Link auf https://www.lesbonscomptes.com/upmpdcli/ , was per Songcast auch synchronisiertes Audio ermöglicht.

Songcast steht schon auf der "für später vielleicht"-Liste. Ich war jedenfalls sehr erfreut zu sehen, dass sowohl Songcast wie auch Snapcast aktiv weiterentwickelt werden.

Inzwischen benutze ich allerdings Amazon Echos in allen Varianten (auch z.B. per Line-in an meinem Receiver).

Gegen diese Art Lösung habe ich einige Vorbehalte, ich will möglichst "cloudfree" bleiben, und wenn es nicht anders geht, ist mir die aktuelle Lösung mit direktem HDMI-Input immer noch lieber wie Line in . Skaliert halt nicht ohne weiteres ...

Mir dräut, ich brauche andere/potentere Server-Hardware, u.A. auch, weil sich RHASSPY sonst ewige Trainingszeiten nehmen muss mit dem, was so angepeilt ist...

[rcmcronny]

Hi,

pulseaudio läuft als Systemdienst.  Die Änderungen an der /etc/pulse/system.pa belaufen sich bei mir auf folgende. Da sind noch ein paar Test Zeilen drin, das klappte damals nicht und bisher hatte ich keine  Zeit, da wieder ranzugehen(notwendig ist es für mich aktuell jedenfalls nicht). Das Ducking ist für die TTS Funktion.

Code Auswählen Erweitern


####custom config#####
#sinks
load-module module-pipe-sink file=/media/snapcast/main.fifo sink_name=main format=s16le rate=48000
load-module module-pipe-sink file=/media/snapcast/kueche.fifo sink_name=kueche format=s16le rate=48000
load-module module-pipe-sink file=/media/snapcast/bad.fifo sink_name=bad format=s16le rate=48000
#test
#load-module module-simple-protocol-tcp sink=main record=true listen=127.0.0.1 port=4747 rate=48000 channels=2 format=s16le
#load-module module-simple-protocol-tcp sink=kueche record=true listen=127.0.0.1 port=4748 rate=48000 channels=2 format=s16le
#load-module module-simple-protocol-tcp sink=bad record=true listen=127.0.0.1 port=4749 rate=48000 channels=2 format=s16le
#combined sinks
load-module module-combine-sink slaves=main,kueche,bad sink_name=alle
# ducking (lower volume during tts announcements
load-module module-role-ducking trigger_roles=announcement ducking_roles=music volume=-20dB global=true

#network
load-module module-native-protocol-tcp auth-anonymous=1 auth-ip-acl=127.0.0.1;10.0.0.0/23
load-module module-zeroconf-publish


Die mpds laufen als Slaves auf der gleichen Datenbank und von der gleichen Quelle, ist für mich nur für "jeder Raum könnte anderes abspielen", in der Regel nutze ich aber den Hauptstream und verteile den  auf die Räume. Der Normale MPD hat als Audio (direkt per Pulse) folgendes: (pa-main ist der normale hauptstream , küche und bad die 2 anderen räume und pa-alle nochmal der sink für alles zusammen)  Das steuere ich dann per Snapcast Modul im FHEM,was aktiv ist etc). Wenn ich ins Bad gehe, schalte ich aktiv zu, mit Logik dann (Läuft ein Stream, schalte dich dazu, wenn nein starte ihn und schalte bad aktiv usw. Ist noch nicht perfekt, für mich aber derzeit ausreichend).
Die 2 Slave MPDs für Bad und Küche laufen mit, und haben dann nur das pa-bad / pa-kueche und pa-alle als sink). Wie gesagt, nutze ich kaum, klappt aber.

Code Auswählen Erweitern


audio_output {
    type            "pulse"
#    media_role      "music"
    name            "pa-main"
    server          "localhost"        # optional
    sink            "main"             # optional
    format          "48000:16:2"
}
audio_output {
    type            "pulse"
#    media_role      "music"
    name            "pa-kueche"
    server          "localhost"        # optional
    sink            "kueche"           # optional
    format          "48000:16:2"
}
audio_output {
    type            "pulse"
#    media_role      "music"
    name            "pa-bad"
    server          "localhost"        # optional
    sink            "bad"              # optional
    format          "48000:16:2"
    mixer_type      "software"
}
audio_output {
    type            "pulse"
#    media_role      "music"
    name            "pa-alle"
    server          "localhost"        # optional
    sink            "alle"              # optional
    format          "48000:16:2"
}

audio_output {
        type            "httpd"
        name            "HTTP Stream"
        encoder         "vorbis"                # optional, vorbis or lame
        port            "8000"
        bind_to_address "0.0.0.0"               # optional, IPv4 or IPv6
        quality         "5.0"                   # do not define if bitrate is defined
#       bitrate         "128"                   # do not define if quality is defined
        format          "44100:16:1"
        max_clients     "10"                     # optional 0=no limit
}


Zusätzlich habe ich ein http stream aktiv, für debugging manchmal nützlich.

Fhem nutzt pulse per /etc/pulse/default.pa:

Code Auswählen Erweitern


load-module module-zeroconf-discover

load-module module-tunnel-sink server=10.0.0.51


Damit stehen die Sinks auch hier zur Verfügung.

Fhem macht TTS bei mir per:

Code Auswählen Erweitern


defmod MyTTS Text2Speech default
attr MyTTS DbLogExclude .*
attr MyTTS TTS_Language Deutsch
attr MyTTS TTS_MplayerCall sudo /opt/fhem/mplayer.sh
attr MyTTS TTS_UseMP3Wrap 1
attr MyTTS room media
attr MyTTS verbose 1


Und die mplayer.sh sieht so aus (man sieht, ist nicht final, eher ein "gefrickel" aber war nie zum zeigen gedacht.

Code Auswählen Erweitern


#!/bin/sh
# zum Test ausgeben
# echo Parameteranzahl $# > /tmp/mplay.txt

# falls volume nicht vorhanden = 1
volume=1
# Dateinamen und Volume ermitteln
while [ $# -gt 0 ]
do
#       echo $1 >> /tmp/mplay.txt
        if [ $1 = -volume ]
        then
                shift
#               echo $1 >> /tmp/mplay.txt
                        if [ $1 -lt 100 ]
                        then
                                volume=0.$(($1))
                        fi
        elif [ -e $1 ]
        then
                file=$1
        fi
        shift
done
# zum Test ausgeben
#echo $volume $file >> /tmp/mplay.txt
PULSE_PROP='media.role=announcement' play -q -v $volume $file
#geht nich   cat ${file} | nc 10.0.0.51 4953
exit 0


So ich hoffe, das waren alle Fragen, falls nicht, bitte nochmal erwähnen. Und natürlich es hilft euch.

Als KVM ist Ubuntu primär wegen dem MPD damit es nicht asbach uralt ist (wie bei Debian). Das LTS alle 2 Jahre ist ne ganz brauchbare Basis find ich. Und als VM braucht der kaum Ressourcen. Läuft auf meinem Linux Rechner halt mit, der ehh läuft.  FHEM auf nem PI4 8GB (extra getrennt, macht einiges leichter, einiges auch schwerer ).

Ronny

[Beta-User]

So, DANKE! - es "zuckt"...

Soundausgabe auf dem Weg MPD@FHEM-Server => pulseaudio@FHEM-Server => Snapcast-Server@FHEM-Server => Snapcast-Client "irgendwo" (auch Medienrechner-HDMI=>Yamaha) läuft prinzipiell .

Was auch anscheinend (prinzipiell) läuft, sind die neuen Modulfassungen zu Snapcast und OpenMultiroom: https://forum.fhem.de/index.php/topic,128206.msg1226511.html#msg1226511, ausgiebiges Testen wäre super (ist aber gefahrgeneigt, u.a. auch deswegen, weil ich noch gar nicht weiß, wie alles geht und auch keine große Testumgebung habe!).

Was bisher nicht klappt, ist eine "einfache Soundausgabe" auf dem Weg mplayer => raop-sink => Yamaha. Es sieht zwar auf der Kommandozeile so aus, als würde was abgespielt, aber effektiv kommt halt nichts aus den Lautsprechern (Befehl(e) liefere ich nach) .

Bevor es einen kleinen update betr. der settings in MPD statt/ergänzend zu Mopidity gibt, noch ein paar Fragen:

pulseaudio läuft als Systemdienst. 

Soweit, so klar. Demnach läuft es nicht als "daemon" (Startoption "-D" in der systemd-service-Datei).

(@Wernieman: vielleicht kannst du mir kurz verklickern, was eigentlich der Unterschied ist zwischen diesen Modi? Oder geht es nur darum, woher die Startparameter kommen (was bei mir bzgl. snapcast angekommen ist: über den -d Parameter wird (u.a.?) gesteuert, woher die Konfiguration gelesen wird.)

Da sind noch ein paar Test Zeilen drin,

Danke, dass du auch deine "unfertigen" Dinge zeigst! So habe ich wenigstens einen Anhaltspunkt und man kann ggf. darüber diskutieren, ob/wie es besser geht!

Das Ducking ist für die TTS Funktion.

OK. Demnach funktioniert das bzgl. des sounds aus MPD auch ohne explizite Angabe der "media_role" (die wenn angegeben anscheinend zu Problemen führt?)

Die mpds laufen als Slaves auf der gleichen Datenbank und von der gleichen Quelle, [...]

Thx, das ist auch das Modell, was mir in etwa vorschwebt. Ich muss nur dann demnächst entscheiden, wie eigentlich die Hardware künftig organisiert werden soll bzw. was ggf. wo laufen darf. ("Server"-) Hardware ist unterwegs, werde dann mal als erstes den Stromverbrauch ansehen und dann entscheiden was und wie.

Fhem macht TTS bei mir per:

Code Auswählen Erweitern


defmod MyTTS Text2Speech default


...also eine Art "Einheitsmodell". Leider ist der "output"-Teil beim Text2Speech-Modul nach meinem Eindruck nicht wirklich gut dokumentiert, aber das (iVm. der .sh) sieht dann so aus, als würde schlicht am FHEM-Server irgendwas ausgegeben? Oder welches Bausteinchen fehlt mir zum Verständnis?

Was TTS angeht, plane ich zur Generierung der Soundfiles eventuell auf "Mimic 3" zu gehen: https://github.com/MycroftAI/mimic3, Ankündigung siehe https://community.rhasspy.org/t/mimic-3-tts-preview/3651. Meine Tests vor Wochen klangen ganz ok, leider war die direkte Einbindung in RHASSPY ein Problem und die Auslastung der Hardware zu hoch, so dass das erst mal auf der Seite gelandet war...

Läuft auf meinem Linux Rechner halt mit, der ehh läuft.

Ist zwar OT, aber warum laufen die MPD dann nicht nativ da drauf? Wegen des separaten pulseaudio-Servers?

Hintergrund der Frage: Falls ich mit der neuen Hardware "einfach nur" meinen alten Wohnzimmer-Rechner ersetze, wird das vermutlich dann (u.A. auch) der "zentrale Soundserver" werden - also ähnlich wie bisher, aber in der "XL-Fassung" mit mehreren MPD-Instanzen, dem snapserver und zwei snapclient-Instanzen. Btw.: TvHeadend läuft darauf dann ggf. auch noch...

[Wernieman]

Als Deamon läuft der pulsaudi immer, als User nur, wenn das passende Programm gestartet wird .. so habe ich es jedenfalls verstanden ..

[Beta-User]

Hmmm, Danke für die Antwort.

Habe dazu noch das hier gefunden (offizielle Doku unter https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Daemon/):

It is a good idea to run the daemon like this:

pulseaudio -D 

This will run /etc/pulse/default.pa after startup. This should be a script written in the CLI language.

Würde das jetzt so interpretieren, dass das "eigentlich nur" darüber entscheidet, ob (auch!) die default.pa geladen wird, oder nur die user-spezifische Konfiguration (abgelegt irgendwo anders).

Aber jetzt habe ich zumindest eine Idee, warum der "-D"-Parameter dazu geführt hat, dass nichts mehr ging: Es wurden die user-spezifische Konfiguration (wegen --sysstem: system.pa) _und_ die _default.pa_ geladen, und da gab es wohl in letzterer was, was kontraproduktiv war (vermutlich: automatisches Entladen von allem, was man nicht braucht)....

Was du beschreibst, würde ich zum einen mit "--system" in Verbindung bringen (läuft, ohne dass ein User eingeloggt sein muss),

Code Auswählen Erweitern

[Service]
ExecStart=/usr/bin/pulseaudio --systemund zum anderen mit "autospawning", also dem (als default hinterlegten) automatischen Start des Dienstes, sobald ihn jemand benötigt.

[rcmcronny]

Hi,

wenn ich mich richtig erinnere, ist die Media Role "music" der Standard und muss nicht angegeben werden.  Klappte bei mir auch nie zuverlässig.
Beim TTS das aber anzugeben sorgt dann erst für die Absenkung der Musik und bessere Verständlichkeit und klappt wie es soll. 

Ich betreibe das in der VM nur, weil ich so das getrennt habe und im Fall der Fälle die VM umziehen kann und auch Backups wiederherstellen usw, machts einfacher, ist aber auch mehr Aufwand wegen Updates usw.
Vielleicht kann man das auch mit Docker in ein Dockerfile quetschen und so ein Kompromis machen. Direkt geht aber auch, so invasiv ist das ja beim Snapcast und mpd nicht Schönes kleines Projekt find ich.

Ich wollte auch erst fertige Hardware usw , aber letztlich hat man dann immer Sachen, die unschön sind. Daher habe ich dann einen Pi Zero (damals 12 Eur glaube rum) mit einem DAC HAT (oder auch AMP  HAT) je nach Boxen und Wünschen besorgt und fahre damit sehr gut. Klein, wenig Strom, SD Karte kann man einfach Sichern und Wiederherstellen bei Bedarf .. und Hardware ist auch flexibel.
In der Küche ist das in so Regalboxen eingebaut (Hinten auf, Alles rein, Buchse für Strom ins Holz einbauen und man kann von Aussen kam sehen, was der kann.

Es gibt auch bei Snapcast ein Projekt den ESP32 mit Sound DAC zu nutzen, scheint aber nur halbgar aktuell zu sein. Das wäre natürlich auch ganz nett, vor allem für TTS Sachen vielleicht.

Ronny

[Beta-User]

OK, dann werde ich den Parameter im Wiki bzgl. MPD/pulse einfach weglassen - dass man zusätzlich bei der "überlagernden Quelle" dann den Parameter mit angeben muss, erscheint logisch.

Wie gesagt: Mit TTS habe ich erst seit RHASSPY was am Hut - aber da dann experimentell auch schon mal mit einem ESP32 (M5 Atom Echo) rumgespielt. Das geht, aber der Ton ist mickrig und - mit den falschen Parametern kompiliert - auch zerhackt. Die nächste Generation kann das vermutlich besser, aber dann sind wir auch strommäßig vermutlich in der selben Liga wie ein Pi. Der Vorteil bliebe, dass man nicht ständig nach updates suchen muss, um das halbwegs sicher zu halten...

Ansonsten bastle ich auch eher "retro-like" Zeug selber oder nehme was gebrauchtes, statt irgendeine neue proprietäre Lösung ins Haus zu holen, von der man nie so recht wissen kann, wann die was wohin sendet.

In die Küche habe ich "damals" ein paar Kabel verlegt, von daher ist der Sound da ordentlich, ganz ohne extra Pi .
"Nur" das Wählen einer passenden Quelle und Umswitchen zwischen verschiedenen Medienarten (und die "Autonomie" zwischen den Zonen) könnte/will ich verbessern.
Aber vielleicht "motze" ich einen alten Radiowecker für's Schlafzimmer auf...?!? Diverse 2-er Pi lägen hier auch noch rum, und ein ungenutzer 3-er samt (mini-) Audio-Hardware wäre auch noch im Fundus, der könnte "nebenbei" noch als RHASSPY-Satellit eingesetzt werden... (Oder kauf' doch mal eines dieser neuen Schnickschnacks, wenn mal klar ist, wie man das generisch ansteuern kann...?).

Optionen über Optionen .

[Wernieman]

Fertiger Docker Container mit MPD/Pulseaudio und SnapCast währe durch aus auch nicht zu verachten ... ;o)

[Beta-User]

Ja...

Hatte auch schon daran gedacht, ggf. auf der neuen Hardware mal LXC auszutesten. docker hätte für mich den (kleinen) Vorteil, dass ich damit schon "Erfahrung" habe (aber eigentlich froh war, als es (damals mit deconz) auch so ging...).

Interessehalber: Was müßte man denn tun/liefern, um eine "Muster-dockerfile" zu erstellen, mit deren Hilfe dann ein Einsteiger (oder jemand, bei dem FHEM schon dockerized ist) dann relativ schnell zu einem lauffähigen System kommen würde? Also (skalierbar) z.B. die 4 Räume/Snapclients aus dem OpenMultiroom-Wiki?

[Wernieman]

Eigentlich mindestens eine docker-compose.yml ... und Dockefiles, die dann den Container erstellen. Würde mich dranmachen, nur fahre ich demnächst in den Urlaub .... (Ohne "nette Inder")

[Beta-User]

Eigentlich mindestens eine docker-compose.yml ... und Dockefiles, die dann den Container erstellen. Würde mich dranmachen, nur fahre ich demnächst in den Urlaub .... (Ohne "nette Inder")

Lass dir Zeit bzw. wir können das dann gerne nach deinem Urlaub nochmal aufgreifen.

Denn

Ich muss nur dann demnächst entscheiden, wie eigentlich die Hardware künftig organisiert werden soll bzw. was ggf. wo laufen darf. ("Server"-) Hardware ist unterwegs, werde dann mal als erstes den Stromverbrauch ansehen und dann entscheiden was und wie.
[...]
Falls ich mit der neuen Hardware "einfach nur" meinen alten Wohnzimmer-Rechner ersetze, wird das vermutlich dann (u.A. auch) der "zentrale Soundserver" werden - also ähnlich wie bisher, aber in der "XL-Fassung" mit mehreren MPD-Instanzen, dem snapserver und zwei snapclient-Instanzen. Btw.: TvHeadend läuft darauf dann ggf. auch noch...

die Hardware ist da . Bis ich die darin verbaute HDD mal abgestöpselt hatte, war ich reichlich enttäuscht ob des Geräuschlevels, und der "Schnelltest" beim Energiebedarf war auch "so so la la". Ohne die HDD: 

Konkreter: Ist ein EliteDesk 800 G4 SFF mit i3-CPU, idle (zeigt nur das Menü zur Sprachauswahl bei der Win-Installation an) scheint der sich ohne HDD <5W zu gönnen ("Messgerät" ist ein innr-Zwischenstecker). Bei Gelegenheit werde ich das eventuell im "Thinclient-Thread" kurz aufgreifen, ist m.E. (abgesehen von den Lüftern) dann auch eine "sehr gute Ersatzlösung" für vergriffene Pi's...

Meine Erwartung ist, dass ich schlicht die SDD's+TV-Karte aus dem vorhandenen Rechner nehme, das alles da reinstecke, ein wenig Spaß mit UEFI habe und dann binnen überschaubarer Frist mehr oder weniger 1:1 den heutigen Stand habe. Nur eben mit mehr Ausbaureserven und deutlich potenterer Hardware . V.a. hat das Ding wieder einen hinten liegenden Kopfhörerausgang, der ggf. sogar digital spricht?
Damit sollte es möglich sein, an dem Yamaha zwei unterschiedliche Schnittstellen ohne großes Netzwerk-Gefrickel (abgesehen von 127.0.0.1) zu beliefern .

Dann wird wohl als nächstes MPD aus der User-Sphäre verbannt und ein paar Slaves dazu angelegt, vermutlich dann RHASSPY (wieder) auf diese Hardware verlegt und

Was TTS angeht, plane ich zur Generierung der Soundfiles eventuell auf "Mimic 3" zu gehen:

Siehe auch https://forum.fhem.de/index.php/topic,128240.0/topicseen.html

Mal sehen...
Erst mal muss die Hardware (weiter-) laufen

[Beta-User]

Erst mal muss die Hardware (weiter-) laufen

Der Teil war erfreulich stressfrei (nachdem die M.2-SSD endlich rausdurfte - nach der "Redmond-typischen Update-Orgie", die man sicherheitshalber benötigt, um alles firmwares+BIOS auf Stand zu bringen...); nicht mal "Spass mit UEFI" war angesagt .

Energiebedarf [...] ("Messgerät" ist ein innr-Zwischenstecker)

Weiter sehr akzeptabel: Natürlich sehr schwankend, je nachdem, was grade abgerufen wird. Ohne dass sonst groß was passiert liegt es grade bei ca. 10-12W (2 SSD, eine Twin-Tuner-Sat-Receiver-Karte für TvHeadend) => deutlich weniger als mein bisher genutzter WYSE-ThinClient.

Interessehalber ging jetzt als erstes "mimic3-server" an den Start - mit "thorsten_low" gibt's einen RTF von < 0.11 und eine Prozessorlast <40%, das ganze funktioniert nun auch mit meiner RHASSPY-Installation (mein erster Test mit der preview-Version vor einigen Wochen war erfolglos geblieben).

Als nächstes geht es dann mal ans Aufräumen und Weiterexperimentieren...

Was mich wundert: Bisher kein einziger Download der neuen Versionen von Snapcast & Openmultiroom...?

EDIT - Noch ein interessanter Fund hier im Forum betr. TTS-Ausgabe via raop: https://forum.fhem.de/index.php/topic,119278.msg1137044.html#msg1137044

[rcmcronny]

Hallo,

Hatte ich wohl übersehen, habe den Thread nun abonniert und die beiden eingespielt.

Ronny

[Beta-User]

So, nachdem es hier eine zeitlang sehr ruhig war, zumindest mal ein Zwischenstand:
- Soundausgabe klappt (mittlerweile anscheinend ohne Aussetzer) auf dem Weg  (alles auf/an derselben Maschine!):

Code Auswählen Erweitern

TvHeadend -> MPD(-User) -> pulseaudio (fifo-sink) -> Snapserver -> Snapclient -> pulseaudio (alsa-sink) -> HDMI -> Yamaha
- Text2Speech generiert mp3's (via Mimic 3, also offline! - Wer es testen will: Die Installation ist in wenigen Minuten erledigt, angepaßtes Modul für FHEM ist in https://forum.fhem.de/index.php/topic,128240.msg1227529.html#msg1227529 zu finden...)

Noch nicht optimal:
- pulseaudio (und MPD) auf dieser Maschine läuft (noch) in der User-Späre. Dadurch muss man auch snapclient noch manuell starten, weil die echten Ausgabe-sinks nicht rechtzeitig verfügbar sind (geplant: noch ein 2., analoger Stereo-Ausgang neben hdmi, vielleicht kann man sogar den im Gehäuse verbauten Lautsprecher direkt und getrennt ansteuern?)
- es gibt noch keinen "entfernten Player", der (Netzwerk-) sinks auf dem "Soundserver" nutzen könnte, und auch die Syntax ist noch zu verifizieren. Material wäre in https://wiki.das-labor.org/w/Audio_Streams zu finden... (irgendwie liest sich das so, als müßten die (module-tunnel-sink-new-) sinks nicht vorher angelegt werden? Kommt mir komisch vor.)
- Das FHEM-Modul für Snapcast scheint noch ein paar Problemchen mit Gruppen zu haben (bitte (noch) nicht austesten! Ist in der Mache.).

Eines nach dem anderen...

[Wernieman]

- pulseaudio (und MPD) auf dieser Maschine läuft (noch) in der User-Späre. Dadurch muss man auch snapclient noch manuell starten, weil die echten Ausgabe-sinks nicht rechtzeitig verfügbar sind (geplant: noch ein 2., analoger Stereo-Ausgang neben hdmi, vielleicht kann man sogar den im Gehäuse verbauten Lautsprecher direkt und getrennt ansteuern?)

Dies ist wirklich ein Problem? Kannst Du denn den snapclient nicht nach pulseaudio starten und damit sollte der sink da sein?

[Beta-User]

Dies ist wirklich ein Problem? Kannst Du denn den snapclient nicht nach pulseaudio starten und damit sollte der sink da sein?

Jein. Das ging vermutlich, wenn ich den snapclient auch in die User-Sphäre verlagern würde - aber ich will eigentlich bei Gelegenheit mal den umgekehrten Weg gehen und Pulseaudio als Systemdienst starten.
Wird aber (vermutlich) noch dauern, muss erst ein paar andere Baustellen wieder zumachen, was ohne Musik weniger spaßig wäre ...

[Wernieman]

Naja ... Systemdienst bedeutet doch auch als User" ....oder willst Du es etwa also root laufen lassen?

P.S. Viel Spaß bei Deinen "anderen Baustellen"!

[Beta-User]

Jein. Wenn ich das richtig verstanden habe, müßte pulseaudio per systemd mit der --system-Option gestartet werden. Das bedeutet afaik nicht zwangsläufig, dass root der owner wird (pulse:audio dürfte der default sein). ABER: Wenn man das so startet, muss man alle anderen User explizit zur Mit-Nutzung zulassen (per HTTP-Freigabe).
Das würde wohl nicht nur das Reihenfolgeproblem mit Snapclient lösen, sondern darüber müßte es dann auch möglich sein, von allen freigegebenen IP-Adressen Sound beizusteuern (also nicht nur beliebige User von localhost, sondern auch vom FHEM-Server aus).

Aber wie gesagt: Bevor ich da versehntlich was grundlegendes verbiege, müssen erst noch ein paar cm Lötzinn weg ...

Danach versuche ich auch, das ganze so zu dokumentieren, dass man es nachvollziehen kann (und ggf. dann auch nur "lokal" nachbasteln).

PS: gestern spuckte der Wohnzimmer-Rechner kurzzeitig Sound aus dem eingebauten Lautsprecherchen. Putzig ... (und für die Spielwiese interessant ).
Ansonsten bin ich mit dem Ding bisher sehr zufrieden.

[Wernieman]

Wie Du merkst, bin ich wieder "im Lande" .. wenn Du also Hilfe brauchst ....

[Beta-User]

Danke!

Werde auf alle Fälle berichten, wenn es weitergeht .

Bis dato klappt jedenfalls die Soundausgabe über den "lokalen Umweg" (aus MPD heraus an Snapcast-Server wie neulich skizziert) tadellos. Das wollte ich so oder so erst mal etwas länger laufen haben bevor es an den weiteren Umbau geht.

Was übrigens doch noch nicht 100% klappt: Die Gruppen-Volume-Steuerung@Snapcast-Modul - die zieht sich immer "alle" Clients als Basis und steuert auch alle. Mir ist das nur "raus", weil der Unterschied bei mir bisher zahlenmäßig effektiv nicht messbar war . Da hatte ich eine "eq" Prüfung testweise ausgehebelt und dann solange an der Gruppensyntax rumgefrickelt, dass ich den Teil glatt übersehen habe. Problemursache kann eigentlich nur das encoding sein, auf dem Bildschirm sieht das alles gleich aus... (Verglichen wird der eingegebene Gruppenname mit den in den Readings gespeicherten Gruppennamen, und die bestehen nur aus Ziffern, Kleinbuchstaben und Bindestrichen!) Also falls da jemand eine Idee hat, wie man dem am einfachsten beikommt...?