Frage zum techn. Ablauf: Qobuz + BubbleUPnP + TV

Bubble UpnP transferiert die Daten zum Renderer, dessen DAC dann benutzt wird.
Ein Problem bleibt aber: In den allermeisten Fällen ist so kein gapless möglich und ob der Fernseher wirklich eine saubere Audioverarbeitung bietet, muss jeder selbst entscheiden.

In den allermeisten Fällen ist hier ein defizierter Client (kann z.B. eine Rasberry Pi mit Volumio sein --> auch mit Bubble UpnP steuerbar, aber als Openhome Renderer ansprechbar und damit gapless) die bessere Variante.
Viele werden sicher auf ein Chromecastgerät verweisen, doch leider kann die Qobuzapp auch hier kein gapless...

Chromcast zum. die TV Variante hat den schlechtesten Sound. Verwende Bubble über Android entweder über Fire-TV, od. direkt über den Marantz Receiver. Klingt Beides um einiges besser wie Chromecast. Bin aber selber auf der Suche nach einer besseren Lösung. Z.B. Notebook & DAC.

Ich hole das jetzt hoch, da es mir auch nicht klar ist.

Same Setup: BubbleUPNP am Android-Gerät und einen Pi als Renderer. Heißt dies, dass das Android Gerät dann gleichzeitig als BubbleUPNP Server funktioniert? Oder ist das dann nur Controlpunkt? Aber wo ist dann der Server?

Mir geht es auch ein wenig um die Auslastung vom WLAN Netzwerk. Vielleicht kann mich jemand erleuchten?

Danke!

BlixaWillBargeld (Beitrag #4) schrieb:

Same Setup: BubbleUPNP am Android-Gerät und einen Pi als Renderer. Heißt dies, dass das Android Gerät dann gleichzeitig als BubbleUPNP Server funktioniert? Oder ist das dann nur Controlpunkt? Aber wo ist dann der Server?

Was möchtest du denn abspielen? Auf dem Smartphone gespeicherte Musik oder Streamingdienste?
BubbleUPnP kann je nach Bedarf als DLNA-Controlpunkt sowie auch als Server funktionieren. Die Verwendung als Renderer ist auch möglich.
Um die Verwirrung noch größer zu machen: Manchmal arbeitet BubbleUPnP auch als Proxy und Transcoder.

Die Belastung für das WLAN-Netzwerk hält sich in Grenzen. Ein 44,1 kHz / 16 bit Stereo WAV-Datenstrom entspricht 1,411 Mbit/s. Selbst wenn im Extremfall die Daten vom Router zum Android-Gerät geleitet werden, dort verarbeitet und wieder zurück zum Router und von dort zum Abspielgerät, sollte das das Netzwerk weniger belasten als das Betrachten eines Youtube-Videos in Full-HD.
Zumal die Musikdatenraten durch die Verwendung von FLAC oder einem anderen Codec noch geringer sind.

Wenn BubbleUPnP nur als Controller arbeitet, werden die Daten direkt vom Server zum Renderer übertragen. Damit sind wir wieder am Anfang. Was soll denn abgespielt werden und wo ist die Musik gespeichert?

Danke für die Antwort, ich vergaß zu erwähnen, dass ich mich auf Qobuz Streaming beziehe, oft auf in 24Bit/96khz.

Und genau das ist dann die Frage: was fungiert da als Server? Android als Controller und Pi als Renderer und was macht den Server? Ich hatte es so verstanden dass immer eine Instanz als Server im lokalen Netzwerk sein muss? Wenn das Android Gerät neben Controller auch als Proxi (Server) fungieren muss, würde das ja bedeuten, dass im WIFI-Netzwerk der Stream doppelt bis dreifach durchläuft (ich hab auch einen PI im WIFI-Netzwerk da nicht verkabelt).

Klar: funktioniert, aber ich habe relativ viele Geräte im Netzwerk, da will ich mit den Bandbreiten etwas aufpassen.

Wenn ich Daten vom Handyspeicher streame, oder aus einer anderen lokalen Quelle, brauche ich einen Server (ob jetzt in der Android-App oder im Netzwerk) wie du schreibst das ist mir klar.

Oh, Qobuz steht ja sogar im Threadtitel. Die Frage nach dem Server hatte mich aber irritiert. Irritierend kann aber möglicherweise auch meine Antwort sein. In der DLNA-Logik ist bei Qobuz-Wiedergabe BubbleUPnP der DLNA-Server. Die an den Renderer übermittelten Links verweisen auf BubbleUPnP. Dort ist aber eine Weiterleitung auf die Qobuz-Server hinterlegt, so dass das Abspielgerät die eigentlichen Musikdaten direkt von Qobuz erhält. Man kann in den Qobuz Einstellungen auch bewusst die Proxy-Funktion einschalten, damit die Daten durch BubbleUPnP durchgeleitet werden. Im Normalfall sollte diese Funktion ausgeschaltet sein.
Ich habe vorhin nochmal getestet. Wenn ich während der Wiedergabe auf dem Smartphone WLAN ausgeschaltet habe, wurde der aktuelle Titel weiter abgespielt. Jede Änderung, wie Vorspulen oder der Übergang zum nächsten Titel erfordert eine Reaktion der BubbleUPnP App.
Möchte man erreichen, dass eine Playlist vollständig ohne Kontakt zum Smartphone abgespielt wird, könnte man die BubbleUPnP-Server Anwendung auf dem Pi installieren, die einen OpenHome-Renderer simulieren kann, der dann von der BubbleUPnP App auf dem Telefon angesprochen werden kann. Alternativ könnte man dann auch die OpenHome Apps wie Linn Kazoo und Lumin nutzen.
Im Alltag sollte es aber reichen, einfach die BubbleUPnP-App ohne zusätzlichen BubbleUPnP-Server zu nutzen.

Danke für die ausführliche Antwort, dass hilft sehr weiter. Vor allem, dass sich der Renderer die Daten dann direkt von Qobuz holt ist das was ich wissen wollte!

Gibt hier wohl viele Möglichkeiten, leider teilweise etwas verwirrend am Anfang. Werde mich da vielleicht die Tage noch mal etwas spielen damit, aber erstmal bin ich beruhigt :).

Viele Grüße

Ich habe in dem Zusammenhang ebenfalls eine Frage zum technischen Verständis.

Fall: UPnP soll den Link zu einem qobuz Stream an den Raspi übertragen, so dass sich dieser den Stream selbst zieht (spart immens Akku auf dem Smartphone).

Meine Frage:
Warum downloaded der Raspi denn die komplette Datei vom qobuz Server (so habe ich es beobachtet, allein schon anhand des Datenvolumens im WLAN wenn ich einen Song immer nur für 5 Sekunden höre und dann zum nächsten springe)?

Ich hatte bisher immer die Vorstellung, dass beim Streaming stets nur das aktuelle Paket und ggf. das nächste gestreamed wird, im Arbeitsspeicher verbleibt und dann wieder verworfen wird. Dürfte auch vom Anbieter von Bedeutung sein, da dieser ja bekanntermaßen nach Millisekunden gehörter Zeit abrechnet und nicht nach Anzahl der Songs usw.

Hier ein Beispiel aus dem Datenprotokoll, das ich bei Spotify angefordert habe (msPlayed: Anzahl gehörter Millisekunden):
{
"endTime" : "2022-01-10 15:19",
"artistName" : "Das Coronavirus-Update von NDR Info",
"trackName" : "Hinweis in eigener Sache",
"msPlayed" : 24188
},

lanturlu (Beitrag #7) schrieb:

Möchte man erreichen, dass eine Playlist vollständig ohne Kontakt zum Smartphone abgespielt wird, könnte man die BubbleUPnP-Server Anwendung auf dem Pi installieren, die einen OpenHome-Renderer simulieren kann, der dann von der BubbleUPnP App auf dem Telefon angesprochen werden kann.

Super! Das ist die Lösung für mein Problem.

Ich habe einen Yamaha MusicCast Audioplayer der in dieser Ausführung kein Qobutz und Tidal unterstützt. So kann ich über UPnP des Gerätes und Bubble Qobutz in HighRes ohne Neuanschaffung nutzen.

Weiß eventuell jemand, ob bei Verwendung der BubbleUPnP App auf dem Android Gerät und Streaming via Tidal (HiFi Plus inkl. MQA) oder qobuz zu einem Raspberry (mit moode oder RuneAudio als Renderer/Verarbeiter) die Qualität auf nur CD-Qualität (16 Bit / 44.1 kHz) beschränkt wird? In der kostenfreien Variante von BubbleUPnP trifft diese Limitierung so zu. Gilt dies aber auch für die Bezahlvariante von BubbleUpnP? Ich meinte vor kurzem in einem Forum gelesen zu haben, dass die Bezahlvariante dies gerade eben nicht beschränken würde.

Die Frage gilt sinngemäß auch für einen Raspberry mit PicorePlayer inklusive LMS und dem dort notwendigen Plugin für Tidal oder qobuz. Hier bin ich mir aber ziemlich sicher, dass dies auf 'nur' CD-Qualität limitiert ist.

Ich habe wieder mal etwas den Überblick verloren. Danke.