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...