/docs · HearLab · Deep

Routage des aides auditives via le framework audio Android

Comment AAudio, ASHA et LE Audio acheminent réellement le son vers les appareils auditifs sur Android moderne.

Diffuser le son d’un téléphone vers une aide auditive semble être un problème qui devrait être résolu. On est en 2026 ; le Bluetooth existe depuis une éternité. Pourtant, la couche de routage est l’une des parties les plus surprenantes de la pile Android, et les éléments qui fonctionnent bien sont précisément ceux qu’aucune application grand public ne met en avant.

Voici une carte pratique de la façon dont le framework audio Android achemine le son vers les appareils auditifs, de ce à quoi sert chaque couche et de l’endroit où vous devez réellement écrire du code si vous concevez des applications de soutien auditif.

Les couches, de haut en bas

App
 ↓
AudioManager / AudioAttributes
 ↓
AAudio / OpenSL ES        ← realtime path
 ↓
Audio HAL
 ↓
Android Bluetooth stack   ← ASHA, LE Audio, Classic A2DP/HFP
 ↓
Hearing device

Chaque couche a ses propres bizarreries. Savoir où écrire votre code représente la moitié du travail.

ASHA : la valeur sûre et établie

ASHA (Audio Streaming for Hearing Aids) était l’ajout de Google, en 2018, à la pile Bluetooth pour la diffusion directe vers les aides auditives. C’est un profil au caractère quasi propriétaire, mais bien documenté, et il constitue la base de la plupart des aides auditives “Made for Android” actuellement sur le marché.

Ce qui fonctionne :

Des flux mono à faible latence en 16 kHz (qualité voix) ou stéréo à des fréquences d’échantillonnage plus élevées.
Directement du téléphone vers l’aide auditive, sans appareil intermédiaire requis.
Une autonomie fiable côté aide auditive (le profil est optimisé pour un faible duty-cycle).
L’intégration aux flux multimédias et d’appel via AudioAttributes.USAGE_VOICE_COMMUNICATION ou USAGE_MEDIA.

Ce qui ne fonctionne pas :

La qualité est pensée pour la parole, pas pour la musique. Un podcast diffusé via ASHA sonne très bien ; une bande-son de film paraît compressée.
Un seul appareil à la fois par flux. Les paires binaurales sont gérées du côté du fabricant de l’aide auditive, pas par l’OS.
Le contrôle depuis l’application sur le codec ou le profil de flux est pratiquement inexistant.

LE Audio : l’avenir, en grande partie arrivé

LE Audio (Bluetooth 5.2+, codec LC3, profil BAP) est le nouveau standard. Il équipe le matériel commercialisé sur la plupart des fleurons Android et une part croissante du milieu de gamme. Depuis fin 2025, il est suffisamment répandu pour qu’un produit sérieux de soutien auditif doive l’anticiper.

Ce qui change :

Le codec LC3 est nettement meilleur que le SBC et concurrence l’AAC en matière de qualité musicale, tout en étant plus efficace.
La prise en charge multi-flux : stéréo vers une paire binaurale sans la colle spécifique au fabricant.
Le Broadcast Audio (Auracast) permet à une seule source de diffuser vers de nombreux appareils, ce qui constitue la base de l’assistive listening dans les espaces publics.
Une meilleure autonomie des deux côtés.

Ce qui pose encore problème :

La prise en charge matérielle est inégale. Les appareils plus anciens n’obtiendront pas LE Audio par mise à jour de l’OS.
L’interface de routage au niveau de l’OS est encore en cours de maturation.
L’adoption d’Auracast dans les espaces publics en est à ses débuts.

Là où vous écrivez réellement du code

Pour une application de soutien auditif, la surface d’intégration est plus réduite qu’il n’y paraît. Trois points :

1. `AudioAttributes.USAGE`

Définissez-le correctement sur vos flux multimédias ou d’appel. L’OS effectue le routage en fonction de l’usage :

val attrs = AudioAttributes.Builder()
    .setUsage(AudioAttributes.USAGE_VOICE_COMMUNICATION)
    .setContentType(AudioAttributes.CONTENT_TYPE_SPEECH)
    .build()

Pour le mode sous-titres de HearLab, USAGE_ASSISTANCE_ACCESSIBILITY est le bon choix : c’est le canal que l’OS utilise pour l’audio d’accessibilité.

2. `MediaRouter` pour la découverte des périphériques de sortie

Si vous voulez savoir si l’utilisateur a une aide auditive appairée et quelles sont ses capacités :

val router = MediaRouter.getInstance(context)
val info = router.selectedRoute
// info.deviceType tells you if it's a hearing aid
// info.supportedTypes tells you what the device can do

Ne présumez pas : vérifiez. Un nombre surprenant d’applications diffusent vers la sortie par défaut sans tenir compte de l’aide auditive de l’utilisateur.

3. AAudio pour une faible latence, là où vous en avez besoin

Pour le sous-titrage en temps réel, le traitement à la fréquence audio ou tout ce où la latence aller-retour compte, utilisez AAudio directement (ou Oboe comme wrapper). La pile audio système ajoute une mise en mémoire tampon que AAudio contourne.

AAudioStreamBuilder *builder = nullptr;
AAudio_createStreamBuilder(&builder);
AAudioStreamBuilder_setDirection(builder, AAUDIO_DIRECTION_OUTPUT);
AAudioStreamBuilder_setSharingMode(builder, AAUDIO_SHARING_MODE_EXCLUSIVE);
AAudioStreamBuilder_setPerformanceMode(builder, AAUDIO_PERFORMANCE_MODE_LOW_LATENCY);

Cela ne route pas directement vers une aide auditive (le routage est décidé une couche plus haut), mais cela vous procure le budget de thread audio nécessaire au travail en temps réel.

Ce que personne ne met en avant

L’interface de loin la plus utile pour un porteur d’aide auditive répond à la question : « où va réellement mon audio en ce moment ? » L’OS Android possède l’information ; personne ne l’affiche.

Si vous concevez la version la plus élémentaire d’une bannière d’état du routage (« Diffusion vers : [nom de l’appareil] via [LE Audio / ASHA / filaire / haut-parleur] ») et que vous l’affichez dès que l’application est au premier plan, vous devancerez instantanément toutes les applications grand public que j’ai testées.

C’est ce que HearLab Companion affiche par défaut. Ce n’est pas techniquement difficile. C’est simplement que le reste du secteur ne s’en donne pas la peine.