Android pose un sacré problème de latence dès qu’il s’agit de transmettre des données audio via le Bluetooth. Grâce à l’expertise d’un spécialiste, nous avons décortiqué le fonctionnement du protocole afin de comprendre cette lacune du système d’exploitation de Google.
Dans le domaine des écouteurs sans fil, les modèles se multiplient depuis plusieurs années. On peut notamment citer les AirPods Pro 2, mais aussi les également citer les Sony WF-1000XM4 ou les Google Pixel Buds Pro, mais il existe évidemment une foultitude de modèles différents. Tous ces produits nous ont poussés à nous intéresser au fonctionnement du Bluetooth audio. L’occasion de nous rendre compte que, sur ce sujet, le système Android n’est pas un élève modèle.
Pour éclairer notre lanterne, nous avons sollicité les précieuses explications de Thomas Girardier, directeur technique (CTO) de Tempow, une entreprise française vieille de sept ans, rachetée fin 2021 par Google, et spécialisée dans les solutions Bluetooth audio qu’elle vend à diverses marques. Avec notre interlocuteur, nous avons abordé les informations importantes à connaître dans ce domaine avant de plonger dans des détails techniques plus complexes mettant en lumière les lacunes d’Android en la matière.
Tout au long de cet article, nous nous attarderons par-ci par-là sur certaines activités de Tempow, car comprendre ce que fait cette entreprise permet, entre autres, de mieux appréhender le sujet qui nous intéresse aujourd’hui. Accrochez-vous bien !
Dissection du Bluetooth audio
Pour comprendre le fonctionnement du Bluetooth audio, il faut connaître quatre éléments importants qui interviennent dans la transmission des données : l’antenne, le contrôleur, le host et la partie applicative. Dans le schéma ci-dessous, nous avons résumé leurs rôles respectifs pour avoir une bonne vue d’ensemble.
Sur votre smartphone Android ou votre appareil Bluetooth (écouteurs, casques, enceintes…), l’antenne est un composant purement matériel, tandis que le contrôleur dépend à la fois du hardware et du software. Les implémentations du host et des couches applicatives sont, elles, pleinement logicielles.
Ainsi, les équipes de Tempow ont pu se spécialiser dans la modification du host et de la partie applicative sur les smartphones Android afin de leur apporter plus de fonctionnalités. Par exemple, c’est grâce à cela que le Motorola Moto X4 peut se connecter à quatre enceintes en même temps pour faire du multi-room. Il en va de même pour le TCL Plex. Ces deux smartphones jouissent d’un partenariat de leurs constructeurs avec la jeune firme française.
Sur Android, les librairies du host et de la partie applicative existent déjà, il suffit donc de les modifier. Ce n’est pas la même histoire sur les casques, les écouteurs ou les enceintes Bluetooth. En effet, sur ces appareils, tout est géré par la puce intégrée à l’intérieur. Or les fournisseurs de puces ne s’occupent que rarement du host et de la partie applicative.
Sur ces produits, Tempow apporte donc son savoir-faire avec ses propres implémentations à ces niveaux-là. En faisant cela, le spécialiste français permet à un constructeur de casques Bluetooth, par exemple, de proposer plus de fonctionnalités « sans être dépendant du hardware embarqué », avance Thomas Girardier.
Tempow vs Qualcomm
Fait intéressant : le concepteur de puces Qualcomm développe ses propres solutions logicielles sur le host et la partie applicative. En cela, le géant de San Diego peut être considéré comme un concurrent de Tempow. Les deux firmes ne collaborent donc jamais.
Pour aller plus loin
Comment Qualcomm est devenu un géant des écouteurs sans fil sans en vendre aucun
À l’inverse, « on collabore avec plein de [d’autres] fabricants de puces pour développer des partenariats et ensuite nous préintégrer sur leurs puces de façon à ce que si un fabricant de produits veut utiliser Tempow, il va pouvoir facilement utiliser n’importe quelle puce compatible avec notre technologie », confie notre interlocuteur.
De leur côté, les technologies de Qualcomm dépendent des SoC Snapdragon. Thomas Girardier défend donc sa paroisse :
Imaginons que je suis Bose et que je développe un produit tout en étant dépendant de la puce de Qualcomm. Si demain je dois changer de puce — en fonction des évolutions du marché par exemple –, je dois absolument tout refaire, toute l’intégration au-dessus de la puce. Ce qui n’est pas le cas pour nous, chez Tempow, puisqu’on va pouvoir utiliser le même software sur différentes puces.
Comment le son est-il transmis aux écouteurs true wireless ?
Intéressons nous maintenant plus spécifiquement aux écouteurs true wireless. Grosso modo, il existe trois manières pour eux de recevoir du son depuis un smartphone. On peut parler de topologies sans fil ou d’architectures.
La première, la plus courante, s’appelle le forwarding. Dans ce cas de figure, le smartphone envoie les deux canaux audio — left et right — à l’un des écouteurs qui se chargera ensuite de les retransmettre au second.
La deuxième architecture est baptisée sniffing. Ici, le smartphone envoie toujours les canaux gauche et droit à un seul écouteur. Or, dans le même temps, la deuxième oreillette vient se faire passer pour le premier afin de récupérer les mêmes données. Cette technique est très utilisée par Apple qui profite de plusieurs brevets empêchant un bon nombre de concurrents d’exploiter cette topologie.
La dernière architecture consiste tout simplement à envoyer le canal left à l’écouteur de gauche et le canal right à celui de droite. C’est la solution que veut pousser Tempow, car elle consomme moins de batterie. En effet, puisque chaque oreillette reçoit moins de données, elle nécessite moins d’énergie. C’est également cette solution qui tend à être poussée avec la nouvelle norme de Bluetooth pour les casques et écouteurs, le Bluetooth LE Audio.
Le hic, c’est que pour proposer cette solution, Tempow doit pousser sa technologie à la fois sur le smartphone et sur les écouteurs. Notons aussi que plusieurs entreprises planchent sur ce genre d’architecture.
Quatre critères pour un équilibre
Nous voilà bien avancés désormais, mais ce n’est pas terminé. Intéressons-nous maintenant aux critères à prendre en compte au moment d’évaluer une solution de Bluetooth audio. Thomas Girardier explique qu’il y en a quatre :
- la synchronisation, valable uniquement pour les écouteurs true wireless, sur les casques il n’y a évidemment pas ce problème ;
- la consommation de batterie ;
- la stabilité qui va de pair avec la qualité audio ;
- la latence.
En ce qui concerne la synchronisation entre les écouteurs d’une même paire, tout dépendra de l’intégration logicielle du fabricant. La consommation de batterie, elle, va beaucoup dépendre du matériel utilisé évidemment et de la topologie sans fil comme nous l’avons expliqué plus haut.
Si la stabilité et la qualité audio sont à considérer ensemble, c’est à cause des codecs Bluetooth audio. Plus le codec offre une haute fidélité lors de la restitution, avec peu de compression (aptX HD, LDAC, HWA…), plus il va utiliser de bande passante. Les risques de saturation sont donc plus élevés, de quoi poser problème à la stabilité du signal. Notons aussi que la qualité audio dépend forcément des codecs matériels tels que le DAC embarqué qui convertit les données du numérique à l’analogique.
Pour aller plus loin
aptX, LDAC, SBC, LC3 : tout comprendre aux codecs Bluetooth audio
Enfin, dès que les smartphones Android sont impliqués, la latence du signal est totalement soumise au comportement de l’OS mobile de Google comme nous le verrons juste après. Mais avant d’aller plus loin, attardons-nous sur une importante notion d’équilibre mise en avant par Thomas Girardier. Ce dernier souligne le fait que pousser la qualité audio via les codecs logiciels a aussi un impact sur la consommation énergétique — plus de données sont envoyées, plus de batterie est consommée.
Les fabricants doivent trouver le bon compromis
« Les fabricants doivent donc trouver le bon compromis entre la qualité audio, la stabilité et l’autonomie de leurs appareils Bluetooth », nous dit le représentant de Tempow. C’est d’ailleurs pour cela que bon nombre d’écouteurs true wireless se contentent d’un codec AAC « qui est le plus équilibré au regard de ces critères », en plus du SBC qui est obligatoire. Il est important d’indiquer ici que le constructeur d’écouteurs ou de casques a le choix d’opter pour la configuration qu’il juge la plus pertinente en fonction du public visé, du prix de vente de son appareil, des ressources à sa disposition, etc.
Or, on ne peut pas du tout dire la même chose pour la latence dès lors qu’Android s’en mêle.
Android et la latence Bluetooth
Sur Android, la latence audio en Bluetooth est particulièrement importante, de l’ordre de 190 à 220 ms selon les modèles de casque, d’écouteur, de smartphone ou de codec utilisé. Cela est dû au fait qu’à plusieurs niveaux, on voit intervenir un buffer ou, en bon français, une mise en mémoire tampon. En effet, pour pouvoir lire les données envoyées par une application de jeu ou de musique, il faut d’abord les recevoir et c’est là qu’intervient l’utilisation d’un buffer.
On trouve déjà un buffer dans l’application mobile dont la longueur dépend de ses développeurs, mais surtout, sur Android, il y a une mise en mémoire tampon d’une durée faramineuse « de 100 à 150 millisecondes » dans le serveur audio, la faute à un manque d’optimisations. Bon à savoir : le serveur audio est un logiciel qui gère l’accès des applications aux fonctionnalités audio du smartphone. Les informations transitent forcément par lui.
Plus de 100 ms de latence subies de base, c’est déjà beaucoup… mais ce n’est pas tout, puisque le host et le contrôleur viennent aussi ajouter leur grain de sel en provoquant de la gigue (jitter en anglais). Pour comprendre ce terme, il faut savoir que le smartphone envoie les données audio au casque par petits paquets de 14,5 ms.
Dans un monde parfait, le casque ou les écouteurs devraient donc pouvoir recevoir un paquet dès qu’ils commencent à lire celui reçu juste avant. Sans prendre en compte les quelque 3 ms que le paquet audio passe dans l’air en moyenne, le laps de temps entre la réception de chaque paquet ne devrait pas excéder 14,5 ms… Oui, dans un monde parfait.
Hélas, c’est là qu’intervient la gigue provoquée par le host et le contrôleur. La gigue, c’est la variation de l’écart entre chaque paquet audio envoyé et ce délai peut atteindre les 60 ms sur Android. En d’autres termes, après avoir joué 14,5 ms d’audio, le casque Bluetooth peut se retrouver avec un vide de 45,5 ms (car 60-14,5=45,5). Vous suivez toujours ? Bien, on peut continuer.
Pour éviter ces « trous » audio, les fabricants de casques et d’écouteurs ajoutent volontairement un buffer sur leurs appareils dès que ces derniers se connectent à un smartphone Android, histoire de pouvoir attendre tranquillement les précieux paquets. C’est une sorte de handicap programmé : « si je sais que je ne vais pas recevoir d’audio pendant 60 ms, il faut que je bufferise pendant au moins 60 ms ».
Cette mise en mémoire tampon supplémentaire varie entre 60 et 100 ms. Sans nous laisser le temps de sortir les calculatrices, Thomas Girardier nous apprend que, globalement, cette latence cumulée sur Android varie entre 180 et 250 ms, voire 300 ms dans certains cas. « C’est donc très compliqué d’avoir une faible latence sur Android ». À titre de comparaison, les AirPods d’Apple ont une latence moyenne de 120 ms.
Quelles conséquences ?
Sur les services de vidéo en streaming comme YouTube ou Netflix, cette latence peut être masquée grâce à un petit ajustement des flux vidéo. À l’instar du buffer des casques Bluetooth, il s’agit là d’une contrainte appliquée volontairement pour masquer la terrible latence aux oreilles et aux yeux de l’utilisateur.
Cette solution ne s’applique cependant pas aux jeux vidéo. Tentez de lancer une partie sur Fortnite ou Call of Duty Mobile avec des écouteurs Bluetooth : vous entendrez le coup de feu de votre arme bien après avoir appuyé sur la détente. Cela est particulièrement déroutant et gâche sensiblement l’expérience. C’est d’ailleurs pour cette raison que les smartphones gaming ne se débarrassent pas de leur prise jack 3,5 mm. Avec un câble, la latence audio est minime.
C’est Google qui devrait faire des efforts
Au fil des années, « Google a fait énormément d’efforts pour améliorer la latence via le câble jack. Mais globalement, sur les dernières versions de l’OS, depuis Android 7 ou 8, il y a eu zéro amélioration sur le Bluetooth », déplore Thomas Girardier.
On le répète donc, un fabricant de casques Bluetooth est généralement impuissant sur la latence audio. Il a la maîtrise sur la qualité et l’autonomie de son produit via quelques compromis, mais « sur la latence, c’est Google qui devrait faire des efforts ».
En attendant, Tempow tente d’optimiser le comportement du serveur audio pour réduire la latence qu’il provoque tout en essayant de réduire la gigue du host en le forçant à prioriser l’envoi des petits paquets audio par rapport aux autres tâches dont il doit s’occuper. Thomas Girardier se targue du fait « qu’avec toutes nos améliorations, on arrive potentiellement à descendre jusqu’à 80 ms ».
De belles promesses. Sachez par ailleurs qu’Android est également un casse-tête pour les plateformes SVoD. Il s’agit d’un autre sujet tout aussi intéressant que nous vous invitons à découvrir.
Pour nous suivre, nous vous invitons à Voir la source
