- Die geringe Audioqualität des standardmäßigen SBC-Codecs liegt nicht nur an Grenzen des Codecs, sondern auch an konservativen Einschränkungen im Bluetooth-Stack und in den Kopfhörereinstellungen; auch bestehende Geräte lassen sich per Softwareänderung verbessern
- Übliche Bluetooth-Stacks handeln 44,1-kHz-Stereo meist mit 328 kbps aus; erzwingt man jedoch Dual Channel, steigt die Bitrate bei gleichem bitpool 53 auf etwa 617 kbps
- Die Patches für Android 8.1 und 9 fügen SBC Dual Channel wie eine HD-Audio-Option zu den Bluetooth-Geräteeinstellungen hinzu und verwenden 551 kbps für EDR-Geräte mit 3 Mb/s sowie 452 kbps für EDR-Geräte mit 2 Mb/s
- 551 kbps und 452 kbps wurden unter Berücksichtigung der Effizienz von Bluetooth-5-Slot-Übertragungen gewählt; erhöht man den bitpool weiter, sinkt die Zahl der gebündelten Frames, was in schlechten Funkumgebungen Aussetzer wahrscheinlicher macht
- Nutzer von LineageOS, Resurrection Remix und crDroid können SBC mit hoher Bitrate per Kontrollkästchen in den Einstellungen aktivieren; Linux-Nutzer erhalten über einen PulseAudio-Patch höhere SBC-Bitraten und Unterstützung für aptX-Varianten
Warum SBC-Audio schlecht klingen kann
- Manche Nutzer von drahtlosen Kopfhörern erleben beim SBC-Codec, den alle Bluetooth-Audiogeräte unterstützen, eine Verschlechterung der Klangqualität und fehlende Höhen
- Eine Möglichkeit ist, Geräte und Kopfhörer mit aptX- oder LDAC-Unterstützung zu kaufen; diese Codecs erfordern jedoch Lizenzgebühren und können den Gerätepreis erhöhen
- Die Hauptursache für die geringe SBC-Qualität sind künstliche Einschränkungen in aktuellen Bluetooth-Stacks und Kopfhörereinstellungen; bestehende Geräte lassen sich per Softwareänderung umgehen
SBC-Parameter und Bitrate
- SBC handelt beim Verbindungsaufbau mehrere Parameter aus
- Typ und Anzahl der Audiokanäle: Joint Stereo, Stereo, Dual Channel, Mono
- Anzahl der Frequenzbänder: 4 oder 8
- Anzahl der Audioblöcke pro Paket: 4, 8, 12, 16
- Verfahren zur Zuweisung von Quantisierungsbits: Loudness, SNR
- minimaler und maximaler bitpool für die Quantisierung: üblicherweise 2..53
- Decoder müssen alle Kombinationen dieser Parameter unterstützen, Encoder können dagegen nur einen Teil implementieren
- Bestehende Bluetooth-Stacks handeln üblicherweise die Kombination Joint Stereo, 8 bands, 16 blocks, Loudness, bitpool 2..53 aus; dabei wird 44,1-kHz-Stereo-Audio mit 328 kbps kodiert
- bitpool ist der Wert, der die Encoding-Bitrate verändert: Je höher der Wert, desto höher Bitrate und Qualität
- Die exakte Zuordnung von bitpool-Wert und Bitrate gilt nur innerhalb eines bestimmten Profils
- Auch Kanaltyp, Anzahl der Frequenzbänder und Anzahl der Audioblöcke haben großen Einfluss auf die Bitrate
- Anders als Stereo oder Joint Stereo kodiert Dual Channel jeden Kanal separat und verwendet pro Kanal einen eigenen bitpool
- Erzwingt man Dual Channel statt Joint Stereo, steigt die Bitrate selbst bei gleichem bitpool 53 auf etwa 617 kbps und damit fast auf das Doppelte
A2DP-Spezifikation und Einschränkungen aktueller Stacks
- Die von 2007 bis 2015 gültige A2DP specification v1.2 verlangte, dass Decoder alle bitpool-Werte unterstützen, die die maximale Bitrate nicht überschreiten
- Dieses Profil begrenzt die maximale Bitrate auf 320 kb/s bei Mono und 512 kb/s in 2-Kanal-Modi
- In der neuen Spezifikation ist keine Bitratenbegrenzung angegeben
- Es wird angenommen, dass aktuelle Kopfhörer mit EDR-Unterstützung, die nach 2015 erschienen sind, bis zu 730 kbps unterstützen können
- Alle getesteten Bluetooth-Stacks — Linux PulseAudio, Android, Blackberry und macOS — setzen dem maximalen bitpool-Parameter künstliche Grenzen
- Fast alle Kopfhörer begrenzen den maximalen bitpool-Wert ebenfalls auf 53
- Mit dem modifizierten Bluetooth-Stack funktionierten die meisten Geräte bei 551 kbps ohne Aussetzer oder Störgeräusche; der standardmäßige Bluetooth-Stack handelt diese Bitrate unter normalen Bedingungen jedoch nicht aus
Patch für den Android-Bluetooth-Stack
- Alle A2DP-kompatiblen Bluetooth-Stacks müssen den Dual-Channel-Modus unterstützen, aber normale Nutzer haben keine Möglichkeit, diesen Modus zu erzwingen
- Die Patches für Android 8.1 und Android 9 fügen Dual Channel dem Stack und dem Entwicklermenü hinzu und behandeln es wie aptX, AAC oder LDAC als HD Audio-Codec-Option in den Bluetooth-Geräteeinstellungen
- Patch-Links
- Dieses Kontrollkästchen schaltet den Dual-Channel-Modus um und verwendet je nach Gerät folgende Bitraten
- EDR-Geräte mit 3 Mb/s: 551 kbps
- EDR-Geräte mit 2 Mb/s: 452 kbps
- Das Patchset wurde in folgende alternative Firmwares übernommen
- LineageOS 15.1: seit 31. März 2019
- LineageOS 16.0: seit 13. Mai 2019
- Resurrection Remix: seit 14. Mai 2019
- crDroid: seit 13. Mai 2019
Warum 551 kbps und 452 kbps gewählt wurden
- Die zeitgeteilte Bluetooth-Übertragung ist darauf ausgelegt, große Pakete mit fester Größe effizient zu senden
- Die maximale Anzahl an Slots pro Übertragung beträgt 5; es gibt auch 1-Slot- und 3-Slot-Übertragungsmodi, aber keine 2-Slot- oder 4-Slot-Modi
- Die bei einer 5-Slot-Übertragung sendbare Datenmenge ist wie folgt
- 2-Mb/s-Verbindung: maximal 679 bytes
- 3-Mb/s-Verbindung: maximal 1021 bytes
- Die maximale Datenmenge einer 3-Slot-Übertragung ist wie folgt
- 2-Mb/s-Verbindung: 367 bytes
- 3-Mb/s-Verbindung: 552 bytes
- Wenn Daten gesendet werden, die größer als 367 bzw. 552 bytes und kleiner als 679 bzw. 1021 bytes sind, wird weiterhin ein 5-Slot-Paket benötigt, wodurch die Übertragungseffizienz sinkt
- Kodiert man 44,1-kHz-Audio mit SBC Dual Channel, bitpool 38, 16 blocks und 8 frequency bands, entstehen 164-byte-Audioframes und eine Bitrate von 452 kbps
- Die Audio-Payload muss mit den Transportprotokollen L2CAP und AVDTP gekapselt werden; dabei gehen von der Audio-Payload 16 bytes Overhead ab
- Bei EDR 2 Mb/s DH5 kann eine 5-Slot-Audioübertragung vier Audioframes enthalten
679 - 4(L2CAP) - 12(AVDTP/RTP) - 1(SBC header) - (164*4) = 6- Im Paket bleiben 6 bytes übrig
- Ein einzelnes Paket enthält bis zu 11,7 ms Audiodaten und wird in 3,75 ms übertragen
- Schon eine kleine Erhöhung des bitpool führt dazu, dass vier Audioframes nicht mehr in eine Übertragung passen und stattdessen jeweils drei gesendet werden müssen
- Die Übertragungseffizienz sinkt
- Die Audiomenge pro Paket wird kleiner
- In schlechten Funkumgebungen steigt die Wahrscheinlichkeit von Audioaussetzern
- 551 kbps für EDR 3 Mb/s wurde nach demselben Prinzip gewählt
- Bei bitpool 47, 16 blocks per frame und 8 frequency bands beträgt die Framegröße 200 bytes
- In einer Übertragung können maximal fünf Frames, also 14,6 ms Musik, gebündelt werden
- Die Berechnung von SBC-Parametern ist komplex und bei manueller Rechnung fehleranfällig; dafür wird ein Webtool bereitgestellt
Unterschiede in der Klangqualität zwischen aptX und SBC
- Entgegen der verbreiteten Annahme, aptX sei immer besser als SBC, kann aptX in manchen Fällen eine geringere Audioqualität liefern als standardmäßiges SBC mit 328 kbps
- SBC weist Frequenzbändern dynamisch Quantisierungsbits zu und verteilt Bits von unten nach oben
- Wenn die gesamte Bitrate für tiefe und mittlere Frequenzen verwendet wird, werden hohe Frequenzen abgeschnitten oder stummgeschaltet
- aptX ist ein Codec mit fester Bitrate, der Frequenzbänder immer mit derselben Anzahl an Bits quantisiert
- 352 kbps bei 44,1 kHz
- 384 kbps bei 48 kHz
- aptX kann Bits nicht auf die benötigten Frequenzen verschieben und schneidet Frequenzen zwar nicht ab, fügt aber Quantisierungsrauschen hinzu, reduziert den Dynamikumfang des Audios und kann gelegentlich Störgeräusche erzeugen
- SBC verwirft dagegen leise Bereiche; im Vergleich zu SBC mit 328 kbps erzeugt aptX bei Musik mit breitem Frequenzbereich im Durchschnitt weniger Verzerrungen
- Bei Musik mit schmalem Frequenzbereich und großem Dynamikumfang kann SBC mit 328 kbps manchmal besser sein als aptX
- In einem Beispiel mit einer Klavieraufnahme lag der größte Teil der Energie zwischen 0 und 4 kHz und reichte bis 10 kHz
- SBC mit 328 kbps schnitt den Bereich oberhalb von 16 kHz periodisch vollständig ab
- aptX brachte mehr Verzerrungen in das für Menschen hörbare Frequenzspektrum ein
- SBC mit 328 kbps erzeugte im Bereich von 0 bis 10 kHz weniger Verzerrungen und schnitt die übrigen Frequenzen ab
- SBC mit 485 kbps reichte aus, um den gesamten Frequenzbereich ohne Abschneiden zu erhalten
- Material mit Originalaudio und SBC-/aptX-kodierten Dateien wird bereitgestellt
- Mit SBC bei hoher Bitrate erhält man in den meisten Fällen einen besseren Klang als mit aptX; SBC mit 551 kbps auf Kopfhörern mit EDR-3-Mb/s-Unterstützung klingt aptX HD sehr nahe
Optionen für höhere Bitraten
- Das Android-Patchset enthält eine zusätzliche Option, um die Bitrate von EDR-2-Mb/s-Geräten weiter zu erhöhen
- Setzt man den Wert
persist.bluetooth.sbc_hd_higher_bitrate auf 1, lässt sich die Bitrate von 452 kbps auf 595 kbps erhöhen
- Diese Option kann in überlasteten Funkumgebungen die Übertragungsstabilität verringern
# setprop persist.bluetooth.sbc_hd_higher_bitrate 1
- Der Patch für extreme Bitraten ist derzeit nur in LineageOS 15.1 gemerged und nicht in LineageOS 16.0
Kompatible Geräte und Vergleichstools
- SBC Dual Channel wird von nahezu allen Kopfhörern, Lautsprechern und Autoradio-Head-Units unterstützt
- Da der Standard von allen decodierenden Geräten die Unterstützung dieses Modus verlangt, funktioniert er auf den meisten Geräten
- Es gibt einige wenige Geräte, bei denen dieser Modus Probleme verursacht, diese Fälle sind jedoch sehr selten
- Informationen zu kompatiblen Geräten finden sich in den folgenden Communities
- Es wird auch ein Webdienst angeboten, der Audio im Browser in Echtzeit nach SBC, aptX und aptX HD kodiert
- btcodecs.valdikss.org.ru/sbc-encoder
- So lassen sich verschiedene SBC-Profile und andere Codecs über kabelgebundene Kopfhörer oder Lautsprecher vergleichen, ohne tatsächlich per Bluetooth zu übertragen
- Die Encoding-Parameter können auch während der Audiowiedergabe direkt geändert werden
Versuch der Aufnahme in AOSP und Verwendung
- Die Entwickler des Bluetooth-Stacks bei Google wurden kontaktiert, damit sie die Patches in den Android-Hauptbranch AOSP aufnehmen, es kam jedoch keine Antwort
- Auch die im Gerrit code review system for Android eingereichten Patches erhielten keine Kommentare von Android-Entwicklungsbeteiligten
- Das Gerrit-Patchset ist eine der alten frühen Revisionen und kann aktualisiert werden, falls Entwickler Interesse zeigen
- Nutzer von LineageOS, Resurrection Remix und crDroid können in den Bluetooth-Geräteeinstellungen das Kontrollkästchen aktivieren, um die Bluetooth-Audioqualität zu verbessern
- Linux-Nutzer können den PulseAudio-Patch von Pali Rohár installieren, um höhere SBC-Bitraten zu verwenden
- Dieser Patch fügt außerdem Unterstützung für die Codecs aptX, aptX HD und FastStream hinzu
1 Kommentare
Hacker-News-Kommentare
Das ist großartig: SBC wird breit unterstützt und wirkt wie eine natürliche Erweiterung des bestehenden Standards.
Persönlich sehe ich das Problem nicht bei SBC vs. LDAC/AAC, sondern darin, dass HFP miserabel ist. Sobald das Mikrofon eingeschaltet wird, fühlt es sich an wie eine Rückkehr in die 90er; wenn man bidirektionales Bluetooth-Audio ordentlich hinbekäme, wäre das wirklich willkommen.
Oder vielleicht ist es AVRCP, aber so oder so klingt es schrecklich.
Dieser Artikel handelt nicht von Bluetooth insgesamt, sondern ist ein tiefer Tauchgang in einen Fehler, der im Android-Bluetooth-Stack vergraben ist.
Was der Autor überhaupt nicht anerkennt, ist die enorme Vielfalt der zugrunde liegenden Hardware. Android läuft auf unzähligen Bluetooth-Chipsätzen; nur weil ein Patch auf der eigenen Hardware zu funktionieren scheint, heißt das nicht, dass er auch auf anderen Android-Telefonen funktioniert.
Außerdem spielt eine Rolle, was das Gerät in diesem Moment gerade tut. Wenn auf einem gemeinsam genutzten BT+Wi-Fi-Chipsatz ein Video per Wi-Fi gestreamt wird, während Audio an Kopfhörer gesendet wird, muss das Gerät Ressourcen zwischen Wi-Fi-Nutzung und Bluetooth aufteilen. Deshalb bekommen lokal gespeichertes Audio und gestreamtes Audio nicht zwangsläufig dieselben Codec-Parameter.
Bei diesem Thema gibt es zu viele Feinheiten, die der Autor nicht berücksichtigt hat; man sollte also vorsichtig sein, was man daraus mitnimmt.
Dadurch kann man eine höhere Bitrate verwenden, ohne den maximalen Bitpool zu überschreiten, den Android und der Bluetooth-Empfänger erzwingen.
Zwischen Source und Sink findet weiterhin eine Aushandlung statt, und wenn eine der beiden Seiten Dual-Channel-SBC nicht unterstützt, fällt sie auf eine unterstützte Variante zurück. Die Geräte, die ich gewartet habe, unterstützten es alle; einige günstige Lautsprecher, die ich damals getestet habe, unterstützten es nicht und handelten stattdessen eine Joint-Stereo-Session aus.
Unter Windows bietet der Alternative A2DP Driver diese Funktion. Er erlaubt das Anpassen von SBC-Parametern und ermöglicht auch AAC oder aptX.
Meiner Erfahrung nach funktioniert er gut und hilft auch dabei, LDAC mit den Sony XM4 zu verwenden. Es ist ein Trial-Modell, aber der Preis ist niedrig.
Ich habe beobachtet, dass die Bluetooth-Reichweite im Hochqualitätsmodus abnimmt; das wirkt wie ein Hinweis darauf, dass sich tatsächlich der Codec oder zumindest irgendetwas ändert und es kein Placebo ist.
Mit https://www.bluetoothgoodies.com/a2dp/ habe ich keinerlei Verbindung.
Der menschliche Hörbereich wird üblicherweise bis 20 KHz angegeben, auch wenn manche junge Menschen etwas höhere Frequenzen hören können.
Zur Info: Auch unter Linux kann man SBC-Audio mit höherer Bitrate über etwas aktivieren, das SBC XQ genannt wird. Ähnlich kann man mit mSBC auch besseres Headset-Audio nutzen.
Natürlich kommt es weiterhin bei weitem nicht an das Niveau von SBC oder aptX heran.
Ich wünschte, Google hätte solche Dinge längst gemergt. Bessere Audio-Codecs werden zwar von vielen Kopfhörern usw. unterstützt, sind aber nicht universell; Verbesserungen bei bidirektionalem Audio fehlen besonders noch.
Ich würde auch gern wissen, wie man prüft, was das aktuelle Headset gerade verwendet.
Ich erinnere mich, früher ein gepatchtes PulseAudio verwendet zu haben, das passende Einstellungen offengelegt hat; später hörte ich, es sei „in den Mainstream gemergt“ worden, konnte dann aber weder Einstellungen noch Informationen zur tatsächlichen Nutzung finden.
Ich wünschte, jemand würde ein Bluetooth-Audioprofil entwickeln, das weit im Voraus puffern kann.
Wenn man zum Beispiel einen einminütigen Song abspielt, sollte der ganze Song im Puffer landen. Natürlich müsste der Puffer verworfen werden, wenn man pausiert oder die Lautstärke ändert.
Mit einem langen Puffer könnte das Telefon häufiger schlafen und Strom sparen, und es würde auch bei schlechter Funkverbindung durchhalten.
Selbst wenn es nur 1–2 MB RAM wären, müssten Kopfhörer wertvolle Akkuladung dafür aufwenden, diesen RAM aktiv zu halten.
Nach dem wenigen, was ich früher mit Audio-Apps gemacht habe, dürfte auch die App-Unterstützung schwierig sein.
Daher ist das weniger ein Protokollproblem als eher eine Funktion, die einzelne Produkte per Design einbauen und die Nutzer in der App ein- und ausschalten können.
Ich habe diese Funktion in LineageOS ausprobiert, und ehrlich gesagt war sie wirklich gut. Ich konnte Audio in höherer Qualität an Geräte wie Autoradios schicken, die keine Drittanbieter-Codecs unterstützen, und auch bei Kopfhörern half es spürbar.
Die User Experience müsste noch geschliffen werden, aber die Funktion selbst ist hervorragend.
Es wäre gut, 2019 in den Titel aufzunehmen. Es kommen Formulierungen wie „alle aktuellen Bluetooth-Stacks“ vor, aber solche Dinge waren schon seit einiger Zeit in PulseAudio und PipeWire implementiert.
Ich bin etwas skeptisch, dass 551 kbps Dual Channel eine deutlich bessere Qualität liefert als 328 kbps Joint Stereo. Es könnte einfach sein, dass mehr Bits darauf verwendet werden, redundante Informationen zu kodieren.
Zumindest gilt das für die meiste Musik; Ausnahmen kann es bei Stücken geben, in denen absichtlich unterschiedliche Aufnahmespuren links und rechts platziert wurden.
Als verwandte Frage: Ich frage mich, ob es eine Möglichkeit gibt, Bluetooth-HFP unter macOS zu verbessern.
Dasselbe Headset nutze ich unter Linux mit mSBC in ziemlich guter Qualität, aber unter macOS ist es völlig miserabel und fällt auf Telefonleitungs-/Mono-Qualität zurück. Ich frage mich, ob es bereits einen Hack gibt, der das unter Darwin richtig zum Laufen bringt.
Bis ich diesen Artikel gesehen habe, wusste ich nicht einmal, dass ich SBC verwende. Lineage 18.1 zeigt dieses UI-Kontrollkästchen nicht an, selbst wenn man ein Gerät verbindet, das SBC unterstützt. Magisch -