Alles Bluetooth oder was? SBC/LDAC/Android/Iphone/DAC/Toslink ... Erfahrungsaustausch

[X-TR4]

Wie du schon sagst, geht es zu einem großen Teil um Reichweite bzw Verbindungsstabilität und eben auch den Akku.
Wenn du mit vollen 50Mbits an deinen BT Kopfhörer streamen würdest und dieser in der Lage wäre das zu verarbeiten, ist vermutlich eher nach 10min statt 10h Akku Schluss.

Was noch ganz erwähnenswert ist: Wer LDAC nutzt, der sollte bei 44.1kHz Quellmaterial kein Oversampling auf 96kHz nutzen,

guter Punkt, von Hires halte ich eh nichts, eventuell gibt das nochmal ein paar % auf Akku oder Reichweite.

edoch fest steht, LDAC ist (unter optimalen Voraussetzungen) der momentan beste HiFi BT Codec, ob man den Unterschied überhaupt hört zu einer "perfekten" Übertragung ist natürlich fraglich und kann im besten Fall wahrscheinlich nur von ganz wenigen unterschieden werden.

Ziemlich sicher nicht. Es gab damals schon Versuche mit MP3 bei "nur" 128 oder 192Kbits.
Wenn das ordentlich codiert wurde konnte da schon niemand den unterschied zur CD erhören. Der MP3 Codec war wohl bereits damals recht performant.
Von daher finde ich das um "Verlustfrei" auch zuviel Wind gemacht wird. Insbesondere wenn man die Nachteile (Akku, Datennutzung) bei mobilen Geräten bedenkt.

Dennoch:
Wenn es die Option gibt, würde ich immer auf die beste Übertragung setzen. Ansonsten habe ich ggfs schon 2 Kompressionen 1x der Musiktitel in der App und dann die Komprimierung ducht den BT Codec.
Das Ganze ist und bleibt ein spannendes und doch irgendwie komplexes Thema

 

[x2max]

Ich sag mal so, wer seine Musik von Spotify streamt bei max 320 kBit/s macht mit den höherwertigeren BT Codecs nichts falsch. Ich nutze Spotify auch hauptsächlich, weiß aber auch das Streaming in CD-Qualität besser sein kann. Die Voraussetzungen die Unterschiede zu erkennen, ist allerdings an einige Bedingungen geknüpft, die auch sehr hohe Hürden für eine aussagekräftige wissenschaftliche Studie stellen würden. Die bisherigen anerkannten Studien dazu (Vergleich: lossless zu sehr guter komprimierter Musik) scheinen wissenschaftlich korrekt zu sein, boten aber auch nicht die richtigen Voraussetzungen, um Unterschiede erkennen lassen zu können.

 

[Cathul]

Den Unterschied finde ich schon deutlich hörbar zwischen 48khz/16bit und 96khz/24bit.

Mit 48khz/16bit fällt der Pegel obenraus ab 16khz schon stark ab.

Dann sind da die entsprechenden Tiefpassfilter falsch implementiert. Der Amir von Audiosciencereview testet sowas regelmäßig bei DACs und regt sich, zurecht, darüber auf.

 

[Cathul]

@x2max Eine Wifi-Verbindung direkt in den DSP (also nicht AndroidAuto/CarPlay; sondern einfach WLAN) sorgt bei den meisten Handys auch dafür, das dann keine mobilen Daten mehr funktionieren; also auch kein Spotify oder Google Maps online.

Zumindest beim iPhone würde es da reichen, dass der DHCP-Server kein Default-Gateway an das Telefon vergibt. Dann geht das iPhone für Datenverbindungen automatisch über das Mobilfunknetz.

 

[Cathul]

Ok, ich kann Eure Argumentation nachvollziehen.


Das ist mir bewusst, ich meine natürlich eine Airplay/Android Cast Lösung im DSP.


Mein Plan sieht so aus, dass ich mir einen günstigen Rasberry besorge, ihn in ein Gehäuse stecke und per Zigarettenanzünder mit Strom versorge. Dieser wird dann per USB an den DSP angeschlossen. Ich verzichte dann auf Carplay/AA. Hauptsache Freisprecheinrichtung funktioniert und Navi benutz ich von der HU. Und wenn ich dann doch mal Carplay brauche, zwitsche manuell um.

Gestern Abend und heute Morgen habe ich einiges zu Bluetooth Codecs gelesen und selbst für den LDAC Codec müsste ich für mich persönlich mit Kompromissen leben, mit denen ich mich nicht herumschlagen möchte. Das ist meine persönliche Meinung und ich will niemanden, für den das die beste Möglichkeit darstellt, auf die Füße treten

Wieso nicht beides?
PI macht nen AP auf, Du streamst per AirPlay auf den PI, der wiederum schiebt die Audiodaten per optischem Kabel in den DSP.
Funktioniert halt nur mit kabelgebundenem CarPlay, aber das sogar recht gut, solange nicht Siri, Whatsapp oder eine sonstige Benachrichtigung den Audiopfad wieder ändert.
Ich habe leider noch keine Möglichkeit gefunden, eine Automatisation zu erstellen, die losläuft, wenn Siri/Whatsapp etc. beendet wird und gleichzeitig CarPlay aktiv ist, den Audiopfad wieder auf das AirPlay Target umlegt.

 

[mr-burns]

Dann sind da die entsprechenden Tiefpassfilter falsch implementiert. Der Amir von Audiosciencereview testet sowas regelmäßig bei DACs und regt sich, zurecht, darüber auf.

Das ist offenbar bei 98% der Geräte einfach so


Gesendet von iPhone mit Tapatalk Pro

 

[Cathul]

Das ist offenbar bei 98% der Geräte einfach so


Gesendet von iPhone mit Tapatalk Pro

Das ist in der Tat so. Die Tests bei Audiosciencereview sind da recht eindeutig. Die große Mehrheit der entsprechenden Geräte haben einen viel zu "sanften" Tiefpassfilter implementiert.

 

[x2max]

Wieso nicht beides?
PI macht nen AP auf, Du streamst per AirPlay auf den PI, der wiederum schiebt die Audiodaten per optischem Kabel in den DSP.
Funktioniert halt nur mit kabelgebundenem CarPlay, aber das sogar recht gut, solange nicht Siri, Whatsapp oder eine sonstige Benachrichtigung den Audiopfad wieder ändert.
Ich habe leider noch keine Möglichkeit gefunden, eine Automatisation zu erstellen, die losläuft, wenn Siri/Whatsapp etc. beendet wird und gleichzeitig CarPlay aktiv ist, den Audiopfad wieder auf das AirPlay Target umlegt.

Du Glücklicher, bei mir funktioniert Carplay nur wireless. Oder gibt es dazu ne Option? Ich denke jedoch nicht, sonst wäre mir das bestimmt irgendwo im Handy- oder HU-Menü aufgefallen. Android Auto geht allerdings per Kabel und wireless.


Noch was Anderes: Welche Vorteile habe ich denn noch so durch einen Rasberry? Ich habe eigentlich nicht vor lokal Musik darauf zu speichern. Im Fokus steht eigentlich nur Streamen und da reicht doch eigentlich ein einfacher Airplay Adapter wie der hier zum Beispiel. Der Rasberry ist zwar günstiger, aber letztendlich doch nicht, weil ich noch ein verhältnismäßig teures (in Wirklichkeit ist es extrem überteuert) Zusatz USB-Modul für den DSP brauche.

 

[LiDoNi]

Ich weis das wollen viele hier GAR NICHT hören, aber viele benutzen Equipment im Bereich Endstufen/DSP, da brauchen sie sich gar keine Gedanken machen welche BT Übertragung sie verwenden.

 

[Cathul]

Du Glücklicher, bei mir funktioniert Carplay nur wireless. Oder gibt es dazu ne Option? Ich denke jedoch nicht, sonst wäre mir das bestimmt irgendwo im Handy- oder HU-Menü aufgefallen. Android Auto geht allerdings per Kabel und wireless.


Noch was Anderes: Welche Vorteile habe ich denn noch so durch einen Rasberry? Ich habe eigentlich nicht vor lokal Musik darauf zu speichern. Im Fokus steht eigentlich nur Streamen und da reicht doch eigentlich ein einfacher Airplay Adapter wie der hier zum Beispiel. Der Rasberry ist zwar günstiger, aber letztendlich doch nicht, weil ich noch ein verhältnismäßig teures (in Wirklichkeit ist es extrem überteuert) Zusatz USB-Modul für den DSP brauche.

Der Belkin braucht ein existierendes WLAN, und das kann nicht das WLAN vom wireless CarPlay sein.

 

[x2max]

Das ist ja määääääh. Dachte das baut ein Ad-hoc WLAN auf...

 

[Cathul]

Das ist ja määääääh. Dachte das baut ein Ad-hoc WLAN auf...

Nein, das steht so aber auch in den Support-Dokumenten von Belkin.
Der Raspi kann einen WLAN AccessPoint öffnen und daher vom iPhone per AirPlay 2 bedient werden.
Mit dem richtigen DSP/DSP-Verstärker kann man, sofern das originale Soundsystem per CAN-Bus gesteuert wird, dann Lautstärke etc. z.B. vom Lenkrad aus im DSP regeln.
Das iPhone kann man so einrichten, dass, sobald CarPlay verbunden wird, automatisch eine Automatisation läuft, die erst die WLAN-SSID abfragt, und bei Übereinstimmung das Wiedergabeziel auf das AirPlay 2 Ziel, sprich den Raspi ändert.

Wofür ich noch keine Lösung habe ist, dass Siri etc. das Wiedergabeziel global wieder zurück setzen. Hier müsste man die Automatisation hinterher nochmal "von Hand" starten, da es für "Siri wird beendet" keine Automatisierung gibt. Ebenfalls gibt es keine Möglichkeit zu überprüfen, ob CarPlay schon läuft, hier gibt es nur CarPlay wird gestartet/beendet.

Man könnte natürlich Siri die Automatisierung per Sprachbefehl ausführen lassen, das habe ich allerdings noch nicht getestet, ob das funktioniert, oder ob Siri nach Rückmeldung nicht direkt das Wiedergabeziel wieder "kaputt" konfiguriert hat.
Ein Zusatz-USB-Modul für den DSP brauchst Du übrigens nicht. Eine simple Hifiberry Digi+ hat einen digitalen optischen und einen koaxialen Ausgang. Mit Alsa kannst Du die eingehenden Daten vom Shairport-Programm dann auf diese Ausgänge routen.

 

[jannek]

Ich hab mal mit der vorliegenden Hardware ein bisschen gemessen. Software RMAA, Testdatei als .wav erzeugt, vom Handy (Pixel 5) per Bluetooth in den BC3 gestreamt und von da per LineOut in die Focusrite 2i2. Momentan limitieren die Werte vom BC3-DAC und der Soundkarte um die extrem guten LDAC Werte vom Amir nachzuvollziehen. Die anderen Sachen wie bei 16kHz abrupt endende Frequenzgänge und starke Unterschiede zwischen Loopback der Soundkarte und Bluetooth sind aber problemlos nachvollziehbar. Als nächstes werde ich daher die ESX 900.7 mal als DAC missbrauchen und schauen ob ich von irgendwo ne Motu M2/M4 kriege.
Interessante Erkenntnis bisher aber: Die THD Werte sind bei Ausgabe über Poweramp rund doppelt so hoch wie bei nem Abspielen aus dem Dateimanager. Irgendwas scheint Poweramt da noch an den Daten zu drehen. Die .wav Datei hat übrigens 48kHz/24bit Auflösung, die Datenübertragung der getesteten Codecs habe ich - sofern möglich - dabei ebenfalls so eingestellt. Resampling sollte es daher nicht sein.
Jemand ne Empfehlung für ne App die möglichst bitgenau zur Bluetooth-Komprimierung ausgibt? Ich werd mal USB Audio Player Pro versuchen...

 

[jannek]

Ich war gestern noch mal bissl fleißig. Um das Thema Signalveränderung durch die abspielende App zu vermeiden (und eine synchronisierte Messung zu ermöglichen indem Quelle und Recorder das RMAA ist) hab ich an meinem Messrechner nen Zusatzprogramm installiert mit dem der Bluetoothcodec einstellbar ist (Bluetooth Tweaker bzw. Alternative A2DP Driver). Nach ein bisschen Fummelei lief das und brachte recht schnell verwertbare Ergebnisse.

Die Loopbackmessung der Focusrite Scarlett 2i2 2nd Gen als Basis ergibt ein THD+N von 0,00178%, also etwas besser sogar als die Werksangabe.



Betrachtet habe ich nur die hochwertigen Bluetoothcodecs, also AAC, AptX HD und LDAC.

Zunächst mal die Frequenzgänge:



Gezoomt:



Schön zu sehen dass bei AAC und AptX HD ab ca. 15 kHz ein Rolloff einsetzt, AAC bei 17 kHz in die "Brick Wall" läuft und AptX HD bei 20 kHz rund 2,5dB unter Bezugsniveau ist. LDAC bleibt bis knapp 21 kHZ sehr nahe am Signal und fällt dann steil ab.


Beim THD+N stellen sich die Codecs folgendermaßen dar:

AAC:



AptX HD:



LDAC:



Hier fällt auf dass LDAC dem Loopback schon sehr nahe kommt. Der THD+N Wert von 0,0022% deckt sich gut mit dem Ergebnis vom Amir. Noch einmal alle zusammen:



Beim Dynamikumfang liegen Loopback, AptX HD und LDAC quasi gleichauf, AAC ist rund 7,5 dB im Nachteil:



Bei der IMD zeigt sich folgendes Bild:





Hier zeigt sich im ersten Bild dass nur LDAC mit dem Loopback vergleichbare Ergebnisse liefert. Das stellt sich auch in den Zahlenwerten (Tabelle siehe unten) so dar. Die extrem schlechten Werte vom AAC möchte ich hier nicht bewerten, das könnte mit der Wahl der Testfrequenzen zusammenhängen. Der "addicted to Audio" misst mit 0,278% beim IMD+N aber ähnlich schlechte Werte.
Das zweite Bild zeigt aber dass LDAC und AAC nahe am Loopback sind und die Kurve vom AAC ab dem Beschnitt des Frequenzgangs abbiegt. AptX HD ist deutlich darüber was sich (hier nachvollziehbar) auch in den Werten zeigt.



Fazit vorerst: Die Überlegenheit vom LDAC ist für mich recht klar nachgewiesen, selbst auf Basis des begrenzenden DACs im BC3. Die Soundkarte wäre relevant geworden wenn ich einen besseren DAC optisch bedient hätte, hab ich mir aus Zeitgründen (Aufbau DSP Amp mit Netzteil etc) jedoch gespart.

Offen bleibt der Nachweis bzw. der Vergleich zu was die Codecs mit digitaler Ausgabe in der Lage sind und Versuche mit welcher App und Einstellung Android das Signal so unbearbeitet wie möglich ausgibt.

Mein BC3 geht heute in die Post zu jemand kompetenterem zum Messen und probieren. 😁

Gruß, jan

 

[Cathul]

Ist AAC mit einem iPhone gemessen, oder auf einem Android basierten Telefon?

Part II: Comparison of Bluetooth Fidelity - AAC encoder quality (Android 10 & 13, Windows 11, Apple iPhones & Mac)

A blog for audiophiles about more objective topics. Measurements of audio gear. Reasonable, realistic, no snakeoil assessment of sound, and equipment.

archimago.blogspot.com

 

[jannek]

Bei meinen gezeigten Messungen ist die Quelle grundsätzlich Windows 11 gewesen.

 

[Cathul]

Ok, dann ist das Ergebnis nur genau für diesen Fall valide.
Problem ist halt, alle Codes sind nur Software und stark abhängig von den verwendeten Bibliotheken zur Implementierung.
Für AAC gibt es etliche Bibliotheken, die stark unterschiedlich in der Qualität sind.
Ich habe einen Sennheiser Momentum 4, der gekoppelt an einen Windows PC gerademal ok klingt, aber sehr gut, wenn er mit dem iPhone gekoppelt ist.
Beide male war es 256kbit AAC (iPhone unterstützt ohne den Sennheiser BT-Adapter nur AAC).

Und das ist einer der Hauptgründe, wieso ich Bluetooh im Auto meide wie der Teufel das Weihwasser.

 

[jannek]

Na dann ist ja gut dass der BC3 jetzt auf dem Weg zu einem eingefleischten Applenutzer ist der den Unterschied zwischen AAC vom PC und vom iPhone perfekt raus messen kann. Wenn AAC vom iPhone in deiner Anwendung super funktioniert - prima.
Allerdings habe ich Zweifel dass man das verallgemeinern kann: https://audiosciencereview.com/foru...luetooth-receiver-bt-codecs.23740/post-798587
Offenbar spielt der Empfänger bzw. die Decodierung auch eine Rolle.
Ich für meinen Teil meide Apple wie der Teufel das Weihwasser und wollte mit dem Test rausfinden ob mir mit Android die AAC / AptX HD Fähigkeit vom DSP reicht oder ich ne Lösung mit LDAC anstrebe - Ergebnis ist klar letzteres.

 

[Cathul]

Mit einem Androiden würde ich persönlich ebenfalls kein AAC nutzen. Die Implementierungen hier sind im Vergleich zu aptX/LDAC einfach immer schlecht.
AAC von Apple auf iOS ist dagegen eine komplett andere Hausnummer, siehe den Link den ich schon gepostet habe. Gibt noch weitere, die eigentlich immer zum gleichen Ergebnis kommen, nämlich: meide AAC auf Android wo es nur geht. Wenn AAC, dann Apple, ansonsten AptX/LDAC.