Si vous avez une petit idée de comment fonctionne un casque Bluetooth, vous savez peut-être que le codec est important. Et si les casques modernes proposent des codecs plutôt performants, à une époque il était possible de travailler en MP3. Ca fait un moment que j’essaye de faire fonctionner un casque dans ce mode pour vérifier un point, et là, j’ai réussi.
Le problème des codecs est souvent assez mal compris. Pour résumer rapidement, le codec de base est le SBC. Il est obligatoire, supporté par tous les appareils et offre une qualité assez moyenne. Il peut être assez bon sur des débits élevés, mais c’est de la bidouille. La norme propose d’autres codecs par défaut (MP3, AAC, etc.) et il existe la possibilité d’ajouter des codecs tiers, comme l’aptX, le LDAC, etc. Le sujet du jour est le MP3, mais il faut bien mettre les choses au point : dans tous les cas, les codecs impliquent des pertes (oui, même le LDAC), et dans 99 %, il y a un encodage lors de l’envoi. On peut lire ici et là (et je l’ai écrit à une époque) qu’Apple envoie l’AAC directement au casque, mais ce n’est pas le cas, j’y reviendrais. Malgré tout, la qualité de l’encodeur joue évidemment sur la perception du son. En AAC, l’encodeur Apple est meilleur (lors de tests en aveugle) que l’encodeur Fraunhofer, lui-même nettement devant une implémentation open source de l’AAC. Plus concrètement, la qualité du son varie en fonction des appareils émetteurs, même en utilisant le même casque. En aptX, le problème n’existe pas car Qualcomm fournit le même encodeur à tout le monde, par exemple.
Le cas MP3
A l’origine, l’idée de l’utilisation du MP3 était d’envoyer directement le son au casque, sans (ré)encodage préalable. C’est a priori ce que font quelques vieux lecteurs pour les smartphones Symbian du début des années 2000, mais c’est un comportement atypique. Dans l’exemple que j’ai pu tester, le MP3 est encodé en temps réel avec un débit assez faible (128 kb/s).
Le casque, le dongle
Il faut le savoir, le codec MP3 n’est utilisé que très rarement en Bluetooth, et pour tester, il y a deux écueils. Premièrement, trouver un périphérique qui accepte le codec. Les casques modernes ne le font généralement pas, il faut aller vers des appareils anciens, et fouiller les fiches techniques. Mon Sony DR-BT22, assez vieux, le propose. Deuxièmement, plus compliqué, l’émetteur doit le supporter aussi. La majorité des OS ne le fait pas, et j’avais trouvé à une époque quelques vieilles versions d’Android sur des appareils précis et c’est tout. macOS ne le fait pas, iOS non plus, avec GNU/Linux, c’est (peut-être) possible en bidouillant, etc. Sous Windows, ça va dépendre du pilote (la stack) et BlueSoleil, de chez IVT, le gère. Là, ça devient embêtant : on parle ici de vieilles versions de BlueSoleil, un pilote qui dépend énormément du dongle choisi. Je vais passer les détails, mais en gros la solution a été d’acheter un dongle Bluetooth d’occasion en espérant (après vérifications) que le pilote livré soit bien BlueSoleil. Et j’ai installé le tout sur un vieux PC sous Windows XP. Dans ce très long article sur les codecs, l’auteur n’a par exemple pas réussi à l’utiliser.
Par défaut, du SBC
Forcer le MP3
Il doit être avant le SBC
Pas de codec MP3 disponible ?
Une fois BlueSoleil installé, il faut forcer le MP3. Par défaut, le son est envoyé en SBC, il faut donc aller dans la configuration du protocole A2DP et mettre le MP3 devant le SBC. Et même après ça, j’ai eu un message d’erreur un peu bizarre : Professional MPEG Layer-3 Codec Not Detected. Après quelques recherches, je me suis rendu compte que le codec de base sous Windows XP est visiblement limité sur l’encodage, et il faut modifier deux entrées de la base de registre.
Dans [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\drivers.desc], remplacer "C:\\Windows\\System32\\l3codeca.acm" par "C:\\Windows\\System32\\l3codecp.acm".
Dans [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32], remplacer "msacm.l3acm"="C:\\Windows\\System32\\l3codeca.acm" par "msacm.l3acm"="C:\\Windows\\System32\\l3codecp.acm".
Après un redémarrage, ça a fonctionné.
Ca marche
La première question à se poser est simple : est-ce qu’il y a une différence audible ? Honnêtement… pas tellement. Le casque est un modèle d’entrée de gamme assez ancien, et je ne peux pas faire de tests en aveugle facilement, vu que le changement de codec nécessite pas mal de manipulations. Je dirais oui parce que je sais que le MP3 est probablement meilleur que le SBC dans le cas présent, mais c’est subjectif. En tout cas, les défauts du MP3 ne sont pas les mêmes à l’écoute que ceux du SBC.
La seconde question, plus intéressant : qu’envoie réellement le programme. BlueSoleil n’indique pas explicitement le débit, mais on peut afficher le nombre d’octets transmis. Donc en lisant le même morceau encore et encore, on peut vérifier ce qu’il envoie. J’ai tenté le même morceau en MP3 à 160 kb/s, en MP3 à 128 kb/s et en WAV (sans compression, donc), avec une transmission en MP3 puis en SBC. En MP3, dans tous les cas, la transmission a donné les mêmes valeurs, qui correspond à du MP3 à 128 kb/s. En SBC, le débit était de ~235 kb/s, donc un bitpool (en gros, les valeurs prédéfinies) de 35. A ce débit, le SBC est considéré comme à peine moyen, mais les casques modernes ont généralement un débit plus élevé (souvent aux alentours de 350 kb/s). Dans les deux cas, on a donc un débit assez faible en Bluetooth, ce qui a un avantage évident : ça coupe assez peu. Avec les appareils modernes, on peut monter un peu plus haut (jusqu’à environ 900 kb/s avec les meilleurs codecs) mais la liaison peut en souffrir.
BlueSoleil indique le nombre d’octets transférés
Globalement, mon petit test a permis de vérifier qu’il est possible de transférer en MP3 depuis un PC, mais c’est à peu près tout : l’intérêt n’est pas évident, surtout avec des appareils aussi vieux et des débits aussi faibles.
