/docs · HearLab · Deep

Routering van hoortoestellen via het Android Audio Framework

Hoe AAudio, ASHA en LE Audio audio daadwerkelijk naar hoortoestellen sturen op moderne Android-apparaten.

Audio van een telefoon naar een hoortoestel streamen klinkt als iets wat allang opgelost zou moeten zijn. Het is 2026; Bluetooth bestaat al een eeuwigheid. Toch is de routeringslaag een van de meest verrassende onderdelen van de Android-stack, en de delen die goed werken zijn precies de delen die geen enkele consumenten-app zichtbaar maakt.

Dit is een praktische kaart van hoe het Android audio framework naar hoortoestellen routeert, waar elke laag goed in is, en waar je echt code moet schrijven als je apps voor hoorondersteuning bouwt.

De lagen, van boven naar beneden

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

Elke laag heeft zijn eigen eigenaardigheden. Weten waar je je code moet schrijven is het halve werk.

ASHA: de gestage gevestigde waarde

ASHA (Audio Streaming for Hearing Aids) was Googles toevoeging uit 2018 aan de Bluetooth-stack voor directe streaming naar hoortoestellen. Het is een profiel met een proprietary-achtig karakter, maar goed gedocumenteerd, en het vormt de basis voor de meeste “Made for Android”-hoortoestellen die momenteel op de markt zijn.

Wat werkt:

Mono-streams met lage latency op 16 kHz (spraakkwaliteit) of stereo op hogere samplerates.
Direct van de telefoon naar het hoortoestel, zonder tussenliggend apparaat.
Betrouwbare batterijduur aan de kant van het hoortoestel (het profiel is geoptimaliseerd voor een lage duty-cycle).
Integratie met media- en gespreksstreams via AudioAttributes.USAGE_VOICE_COMMUNICATION of USAGE_MEDIA.

Wat niet werkt:

De kwaliteit is afgestemd op spraak, niet op muziek. Een podcast via ASHA klinkt prima; een filmscore klinkt gecomprimeerd.
Slechts één apparaat tegelijk per stream. Binaurale paren worden afgehandeld aan de kant van de fabrikant van het hoortoestel, niet door het OS.
Controle vanuit de app over de codec of het streamprofiel ontbreekt vrijwel volledig.

LE Audio: de toekomst, grotendeels gearriveerd

LE Audio (Bluetooth 5.2+, LC3-codec, BAP-profiel) is de nieuwe standaard. Het zit in verscheepte hardware op de meeste Android-vlaggenschepen en in een toenemend deel van het middensegment. Sinds eind 2025 is het mainstream genoeg dat een serieus product voor hoorondersteuning er rekening mee moet houden.

Wat verandert:

De LC3-codec is wezenlijk beter dan SBC en concurrerend met AAC qua muziekkwaliteit, terwijl hij efficiënter is.
Ondersteuning voor multi-stream: stereo naar een binauraal paar zonder de fabrikant-specifieke lijm.
Met Broadcast Audio (Auracast) kan één bron naar meerdere apparaten streamen, de basis voor assistive listening in publieke ruimtes.
Betere batterijduur aan beide kanten.

Wat nog steeds dwarszit:

De hardware-ondersteuning is ongelijk. Oudere apparaten krijgen LE Audio niet via een OS-update.
De routerings-UI op OS-niveau is nog in ontwikkeling.
De adoptie van Auracast in publieke ruimtes staat nog in de kinderschoenen.

Waar je daadwerkelijk code schrijft

Voor een app voor hoorondersteuning is het integratieoppervlak kleiner dan het lijkt. Drie punten:

1. `AudioAttributes.USAGE`

Stel dit correct in op je media- of gespreksstreams. Het OS routeert op basis van usage:

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

Voor de captions-modus van HearLab is USAGE_ASSISTANCE_ACCESSIBILITY de juiste keuze: dat is het kanaal dat het OS gebruikt voor accessibility-audio.

2. `MediaRouter` voor het ontdekken van uitvoerapparaten

Als je wilt weten of de gebruiker een hoortoestel heeft gekoppeld en wat de mogelijkheden ervan zijn:

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

Ga er niet vanuit; controleer het. Een verrassend aantal apps streamt naar de standaarduitvoer zonder rekening te houden met het hoortoestel van de gebruiker.

3. AAudio voor lage latency, waar je het nodig hebt

Voor realtime captioning, verwerking op audio-rate, of alles waarbij round-trip latency telt, gebruik je AAudio rechtstreeks (of Oboe als wrapper). De systeem-audiostack voegt buffering toe die AAudio omzeilt.

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);

Dit routeert niet rechtstreeks naar een hoortoestel (de routering wordt een laag hoger bepaald), maar het geeft je wel het budget op de audiothread dat je nodig hebt voor realtime werk.

Wat niemand zichtbaar maakt

De allernuttigste UI voor een gebruiker van een hoortoestel is “waar gaat mijn audio op dit moment eigenlijk naartoe?” Het Android-OS heeft die informatie; niemand laat het zien.

Als je de meest basale versie bouwt van een banner met de routeringsstatus (“Streamt naar: [apparaatnaam] via [LE Audio / ASHA / bedraad / luidspreker]”) en die toont zodra de app op de voorgrond staat, loop je meteen voor op elke consumenten-app die ik heb getest.

Dit is wat HearLab Companion standaard laat zien. Het is technisch niet moeilijk. Het is gewoon dat de rest van de branche er de moeite niet voor neemt.