- La faible qualité audio du codec SBC standard ne vient pas seulement des limites du codec, mais aussi des restrictions conservatrices de la pile Bluetooth et des réglages des casques ; les appareils existants peuvent donc encore être améliorés par des modifications logicielles
- Les piles Bluetooth courantes négocient généralement la stéréo 44,1 kHz à 328 kbps, mais en forçant le mode Dual Channel, on peut atteindre environ 617 kbps avec le même bitpool 53
- Les correctifs pour Android 8.1 et 9 ajoutent SBC Dual Channel aux réglages des appareils Bluetooth comme une option HD Audio, et utilisent 551 kbps pour les appareils EDR 3 Mb/s et 452 kbps pour les appareils EDR 2 Mb/s
- Les valeurs 551 kbps et 452 kbps tiennent compte de l’efficacité de la transmission Bluetooth sur 5 slots ; augmenter encore le bitpool réduit le nombre de trames regroupées et accroît le risque de coupures dans de mauvaises conditions radio
- Les utilisateurs de LineageOS, Resurrection Remix et crDroid peuvent activer le SBC à haut débit via une case à cocher dans les réglages, tandis que les utilisateurs de Linux peuvent obtenir des débits SBC plus élevés et la prise en charge des variantes d’aptX avec un correctif PulseAudio
Pourquoi SBC donne l’impression d’une faible qualité sonore
- Certains utilisateurs de casques sans fil constatent une dégradation de la qualité audio et un manque d’aigus avec le codec SBC, pris en charge par tous les appareils audio Bluetooth
- Une solution consiste à acheter un appareil et un casque compatibles aptX ou LDAC, mais ces codecs nécessitent des frais de licence et peuvent augmenter le prix des appareils
- La cause principale de la faible qualité du SBC tient aux limitations artificielles des piles Bluetooth et des réglages de casques actuels, que des modifications logicielles permettent de contourner même sur du matériel existant
Paramètres SBC et débit binaire
- SBC négocie plusieurs paramètres lors de l’établissement de la connexion
- Type et nombre de canaux audio : Joint Stereo, Stereo, Dual Channel, Mono
- Nombre de bandes de fréquences : 4 ou 8
- Nombre de blocs audio dans un paquet : 4, 8, 12, 16
- Méthode d’allocation des bits de quantification : Loudness, SNR
- Bitpool minimal et maximal utilisé pour la quantification : généralement 2..53
- Le décodeur doit prendre en charge toutes ces combinaisons de paramètres, mais l’encodeur peut n’en implémenter qu’une partie
- Les piles Bluetooth existantes négocient en général la combinaison Joint Stereo, 8 bands, 16 blocks, Loudness, bitpool 2..53 ; l’audio stéréo 44,1 kHz est alors encodé à 328 kbps
- Le bitpool est la valeur qui fait varier le débit d’encodage : plus elle est élevée, plus le débit et la qualité augmentent
- La correspondance exacte entre valeur de bitpool et débit n’est valable qu’à l’intérieur d’un profil donné
- Le type de canal, le nombre de bandes de fréquences et le nombre de blocs audio ont aussi une forte influence sur le débit
- Contrairement à Stereo ou Joint Stereo, Dual Channel encode chaque canal séparément et utilise un bitpool distinct pour chaque canal
- Forcer Dual Channel au lieu de Joint Stereo porte le débit, avec le même bitpool 53, à environ 617 kbps, soit presque le double
Spécification A2DP et limites des piles actuelles
- La spécification A2DP v1.2, en vigueur de 2007 à 2015, exigeait que le décodeur prenne en charge toutes les valeurs de bitpool ne dépassant pas le débit maximal
- Ce profil limitait le débit maximal à 320 kb/s en mono et à 512 kb/s en mode deux canaux
- La nouvelle spécification ne mentionne pas de limite de débit
- On peut supposer que les casques récents compatibles EDR sortis après 2015 peuvent prendre en charge jusqu’à 730 kbps
- Les piles Bluetooth testées — Linux PulseAudio, Android, Blackberry et macOS — imposent toutes une limite artificielle au paramètre de bitpool maximal
- Presque tous les casques limitent eux aussi la valeur maximale du bitpool à 53
- Avec une pile Bluetooth modifiée, la plupart des appareils ont fonctionné à 551 kbps sans coupures ni bruit parasite, mais les piles Bluetooth par défaut ne négocient pas ce débit dans des conditions normales
Correctif de la pile Bluetooth Android
- Toutes les piles Bluetooth compatibles A2DP doivent prendre en charge le mode Dual Channel, mais l’utilisateur ordinaire ne dispose d’aucun moyen pour le forcer
- Les correctifs pour Android 8.1 et Android 9 ajoutent Dual Channel à la pile et au menu développeur, et le traitent comme une option de codec HD Audio dans les réglages des appareils Bluetooth, au même titre qu’aptX, AAC ou LDAC
- Liens vers les correctifs
- Cette case à cocher active ou désactive le mode Dual Channel et utilise les débits suivants selon l’appareil
- Appareils EDR 3 Mb/s : 551 kbps
- Appareils EDR 2 Mb/s : 452 kbps
- Le jeu de correctifs a été intégré aux firmwares alternatifs suivants
- LineageOS 15.1 : depuis le 31 mars 2019
- LineageOS 16.0 : depuis le 13 mai 2019
- Resurrection Remix : depuis le 14 mai 2019
- crDroid : depuis le 13 mai 2019
Pourquoi avoir choisi 551 kbps et 452 kbps
- La transmission Bluetooth par multiplexage temporel est conçue pour envoyer efficacement de gros paquets de taille fixe
- Le nombre maximal de slots pouvant être envoyés en une transmission est de 5 ; il existe aussi des modes de transmission à 1 slot et 3 slots, mais pas de modes à 2 ou 4 slots
- La quantité de données pouvant être envoyée en transmission 5 slots est la suivante
- Connexion 2 Mbps : jusqu’à 679 bytes
- Connexion 3 Mbps : jusqu’à 1021 bytes
- La quantité maximale de données en transmission 3 slots est la suivante
- Connexion 2 Mbps : 367 bytes
- Connexion 3 Mbps : 552 bytes
- Si l’on envoie plus de 367 ou 552 bytes mais moins de 679 ou 1021 bytes, 5 slots restent nécessaires, ce qui réduit l’efficacité de transmission
- En encodant de l’audio 44,1 kHz en SBC Dual Channel, bitpool 38, 16 blocks, 8 frequency bands, on obtient des trames audio de 164 bytes et un débit de 452 kbps
- La charge utile audio doit être encapsulée par les protocoles de transport L2CAP et AVDTP, ce qui retranche 16 bytes de surcharge à la charge utile audio
- En EDR 2 Mb/s DH5, une transmission audio 5 slots peut contenir 4 trames audio
679 - 4(L2CAP) - 12(AVDTP/RTP) - 1(SBC header) - (164*4) = 6- Il reste 6 bytes dans le paquet
- Un paquet unique contient jusqu’à 11,7 ms de données audio et est transmis en 3,75 ms
- Augmenter le bitpool, même légèrement, empêche de faire tenir 4 trames audio dans une seule transmission, obligeant à les envoyer par groupes de 3
- L’efficacité de transmission diminue
- La quantité d’audio contenue dans un paquet se réduit
- Le risque de coupures audio augmente dans de mauvaises conditions radio
- Le 551 kbps pour EDR 3 Mb/s a été choisi selon le même principe
- Avec bitpool 47, 16 blocks per frame et 8 frequency bands, la taille d’une trame est de 200 bytes
- Une transmission peut regrouper jusqu’à 5 trames, soit 14,6 ms de musique
- Le calcul des paramètres SBC est complexe et les erreurs sont faciles dans un calcul manuel ; un outil web de calcul est fourni
Différence de qualité audio entre aptX et SBC
- Contrairement à l’idée reçue selon laquelle aptX serait toujours meilleur que SBC, aptX peut dans certains cas produire une qualité inférieure au SBC 328 kbps standard
- SBC attribue dynamiquement les bits de quantification aux bandes de fréquences, en les répartissant du bas vers le haut
- Si tout le débit est utilisé pour les basses et les fréquences moyennes, les hautes fréquences sont coupées ou mises en silence
- aptX est un codec à débit fixe qui quantifie toujours les bandes de fréquences avec le même nombre de bits
- 352 kbps à 44,1 kHz
- 384 kbps à 48 kHz
- aptX ne peut pas déplacer les bits vers les fréquences qui en ont besoin et, même s’il ne coupe pas les fréquences, il ajoute du bruit de quantification, réduit la plage dynamique de l’audio et peut parfois générer du bruit
- À l’inverse, SBC abandonne les zones silencieuses ; comparé au SBC 328 kbps, aptX produit en moyenne moins de distorsion sur de la musique couvrant une large plage de fréquences
- Sur de la musique avec une plage de fréquences étroite et une large plage dynamique, le SBC 328 kbps peut parfois faire mieux qu’aptX
- Dans l’exemple d’un enregistrement de piano, l’essentiel de l’énergie se situe entre 0 et 4 kHz et s’étend jusqu’à 10 kHz
- Le SBC 328 kbps coupait périodiquement complètement la plage au-delà de 16 kHz
- aptX introduisait davantage de distorsion dans le spectre de fréquences audible par l’humain
- Le SBC 328 kbps produisait moins de distorsion dans la plage 0–10 kHz et coupait les autres fréquences
- SBC 485 kbps était suffisant pour préserver toute la plage de fréquences sans la couper
- Les fichiers audio originaux et les fichiers encodés en SBC/aptX sont fournis
- En utilisant SBC à haut débit, on obtient dans la plupart des cas un meilleur son qu’avec aptX ; sur les casques compatibles EDR 3 Mb/s, SBC 551 kbps offre un son très proche d’aptX HD
Options de débit plus élevé
- Le jeu de correctifs Android inclut une option supplémentaire pour augmenter le débit des appareils EDR 2 Mb/s
- En définissant
persist.bluetooth.sbc_hd_higher_bitrate à 1, il est possible de faire passer le débit de 452 kbps à 595 kbps
- Cette option peut réduire la stabilité de transmission dans un environnement radio encombré
# setprop persist.bluetooth.sbc_hd_higher_bitrate 1
- Le correctif de débit extrême n’est actuellement intégré qu’à LineageOS 15.1, et pas à LineageOS 16.0
Appareils compatibles et outils de comparaison
- SBC Dual Channel est pris en charge par presque tous les casques, enceintes et autoradios
- Comme la norme exige la prise en charge de ce mode par tous les appareils de décodage, il fonctionne sur la plupart des appareils
- Quelques appareils présentent des problèmes dans ce mode, mais ces cas restent très rares
- Des informations sur les appareils compatibles sont disponibles dans les communautés suivantes
- Un service web permet aussi d’encoder l’audio en temps réel dans le navigateur en SBC, aptX et aptX HD
- btcodecs.valdikss.org.ru/sbc-encoder
- Il permet de comparer le rendu de plusieurs profils SBC et d’autres codecs sur un casque ou des enceintes filaires, sans transmission Bluetooth réelle
- Les paramètres d’encodage peuvent être modifiés directement pendant la lecture audio
Tentative d’intégration à AOSP et mode d’emploi
- Les développeurs de la pile Bluetooth de Google ont été contactés pour leur demander d’inclure le correctif dans AOSP, la branche principale d’Android, mais aucune réponse n’a été reçue
- Le correctif publié sur le système de revue de code Gerrit pour Android n’a pas non plus reçu de commentaires de la part des personnes impliquées dans le développement d’Android
- Le jeu de correctifs Gerrit correspond à l’une des anciennes révisions initiales, et peut être mis à jour si des développeurs s’y intéressent
- Les utilisateurs de LineageOS, Resurrection Remix et crDroid peuvent améliorer la qualité audio Bluetooth en activant la case à cocher dans les réglages de l’appareil Bluetooth
- Les utilisateurs de Linux peuvent installer le correctif PulseAudio de Pali Rohár pour utiliser des débits SBC plus élevés
- Ce correctif ajoute aussi la prise en charge des codecs aptX, aptX HD et FastStream
1 commentaires
Avis sur Hacker News
C’est excellent : SBC est largement pris en charge, et cela ressemble à une extension naturelle du standard existant.
Personnellement, le problème n’est pas tant SBC contre LDAC/AAC, mais le fait que HFP soit médiocre. Dès que le micro s’active, on a l’impression de revenir dans les années 90, et si l’on pouvait enfin faire fonctionner correctement l’audio Bluetooth bidirectionnel, ce serait vraiment bienvenu.
Ou alors c’est peut-être AVRCP, mais dans tous les cas le son est horrible.
Cet article ne parle pas du Bluetooth en général, mais creuse en profondeur un bug enfoui dans la pile Bluetooth d’Android.
Un point que l’auteur ne reconnaît pas du tout est l’immense diversité du matériel sous-jacent. Android fonctionne sur d’innombrables chipsets Bluetooth ; le fait qu’un patch semble fonctionner sur son matériel ne garantit donc pas qu’il fonctionnera sur d’autres téléphones Android.
Ce que fait l’appareil à ce moment-là joue aussi. Sur un chipset partagé BT+Wi-Fi, si l’on streame de la vidéo en Wi-Fi tout en envoyant l’audio vers un casque, l’appareil doit répartir ses ressources entre l’usage du Wi-Fi et le Bluetooth. Ainsi, l’audio stocké localement et l’audio en streaming ne reçoivent pas forcément les mêmes paramètres de codec.
Il y a trop de subtilités sur ce sujet que l’auteur n’a pas prises en compte ; il faut donc lire cela avec prudence.
Cela permet d’utiliser un débit plus élevé sans dépasser le bitpool maximal imposé par Android et par le récepteur Bluetooth.
La négociation entre la source et le récepteur a toujours lieu, et si l’un des deux ne prend pas en charge le SBC dual channel, on revient à un mode pris en charge. Tous les appareils que je maintenais le prenaient en charge ; certains haut-parleurs bon marché que j’avais testés à l’époque ne le faisaient pas, et la session était donc négociée en joint stereo.
Sous Windows, Alternative A2DP Driver fournit cette fonctionnalité. Il permet d’ajuster les paramètres SBC, et aussi d’utiliser AAC ou aptX.
D’après mon expérience, cela fonctionne bien, et cela m’aide aussi à utiliser LDAC avec un Sony XM4. C’est un modèle avec version d’essai, mais le prix est raisonnable.
J’ai déjà constaté que la portée Bluetooth diminuait en mode haute qualité, ce qui semble indiquer que le codec, ou au moins quelque chose, change réellement et que ce n’est pas un placebo.
Aucun lien avec https://www.bluetoothgoodies.com/a2dp/.
La plage audible humaine est généralement documentée jusqu’à 20 kHz, même si certains jeunes peuvent entendre des fréquences légèrement supérieures.
Pour info, sous Linux aussi on peut activer de l’audio SBC à plus haut débit avec une méthode appelée SBC XQ. De manière similaire, on peut aussi utiliser mSBC pour un meilleur son de casque avec micro.
Bien sûr, cela reste encore très loin du niveau de SBC ou d’aptX.
J’aimerais que Google ait déjà intégré ce genre de choses. De meilleurs codecs audio sont pris en charge par beaucoup de casques et autres appareils, mais pas universellement, et les améliorations de l’audio bidirectionnel restent particulièrement insuffisantes.
J’aimerais aussi savoir comment vérifier ce que mon casque utilise actuellement.
Je me souviens avoir utilisé autrefois un PulseAudio patché qui exposait les bons réglages ; plus tard, j’ai entendu dire que cela avait été « intégré au mainstream », mais je n’ai jamais réussi à trouver les réglages ni les informations d’utilisation réelle.
J’aimerais que quelqu’un crée un profil audio Bluetooth capable de mettre longtemps en mémoire tampon à l’avance.
Par exemple, si l’on lit une chanson d’une minute, toute la chanson devrait être chargée dans le tampon. Bien sûr, si l’on met en pause ou que l’on change le volume, le tampon devrait être abandonné.
Avec un long tampon, le téléphone pourrait se mettre en veille plus souvent et économiser de l’énergie, tout en mieux résistant aux mauvaises connexions sans fil.
Même s’il ne s’agit que de 1 à 2 Mo de RAM, le casque devrait dépenser une précieuse énergie de batterie pour maintenir cette RAM active.
Pour avoir un peu travaillé sur des apps audio par le passé, je pense aussi que la prise en charge côté application serait délicate.
C’est donc moins un problème de protocole qu’une fonctionnalité que des produits particuliers intégreraient dans leur conception, avec une option activable ou désactivable par l’utilisateur dans l’app.
J’ai essayé cette fonctionnalité dans LineageOS et, franchement, c’était vraiment bien. Cela permettait d’envoyer un son de meilleure qualité à des équipements comme des autoradios qui ne prennent pas en charge les codecs tiers, et cela aidait aussi pas mal avec les casques.
L’expérience utilisateur avait besoin d’être peaufinée, mais la fonctionnalité elle-même était excellente.
Il faudrait ajouter 2019 au titre. On y trouve des formulations comme « toutes les piles Bluetooth actuelles », mais ces choses sont implémentées depuis un moment déjà dans PulseAudio et PipeWire.
Je suis un peu sceptique quant au fait que le Dual Channel à 551 kbps donne une qualité sensiblement meilleure que le Joint Stereo à 328 kbps. Il se peut que cela utilise simplement plus de bits pour encoder des informations redondantes.
C’est au moins le cas pour la plupart des morceaux, même s’il peut y avoir des exceptions, comme des titres qui placent volontairement des pistes d’enregistrement différentes à gauche et à droite.
Question liée : je me demande s’il existe un moyen d’améliorer le HFP Bluetooth sous macOS.
J’utilise le même casque sous Linux avec mSBC et une qualité plutôt correcte, alors que sous macOS c’est totalement médiocre et cela bascule vers une qualité ligne téléphonique/mono. Je me demande s’il existe déjà un hack pour le faire fonctionner correctement sous Darwin.
Avant de lire cet article, je ne savais même pas que j’utilisais SBC. Lineage 18.1 n’affiche pas cette case dans l’UI même quand on connecte un appareil compatible SBC. Magique -