L'accessibilité des appareils auditifs (HA) peut être améliorée sur les appareils mobiles Android en utilisant des canaux L2CAP (CoC) orientés connexion via le Bluetooth à basse consommation (BLE). CoC utilise un tampon élastique de plusieurs paquets audio pour maintenir un flux audio constant, même en cas de perte de paquets. Ce tampon offre une qualité audio pour les appareils auditifs au détriment de la latence.
La conception du CoC fait référence à la spécification de base Bluetooth version 5 (BT). Pour respecter les spécifications de base, toutes les valeurs multi-octets de cette page doivent être lues en ordre octets de poids faible.
Terminologie
- Central : appareil Android qui recherche des annonces via le Bluetooth.
- Périphérique : appareil auditif qui envoie des paquets d'annonces via Bluetooth.
Topologie réseau et architecture système
Lorsque vous utilisez la CoC pour les prothèses auditives, la topologie réseau suppose un seul appareil central et deux périphériques, un à gauche et un à droite, comme illustré à la figure 1. Le système audio Bluetooth considère les périphériques gauche et droit comme un seul puits audio. Si un périphérique est manquant, en raison d'un ajustement mono ou d'une perte de connexion, le périphérique central mixe les canaux audio gauche et droit, puis transmet le son au périphérique restant. Si la centrale perd la connexion avec les deux périphériques, elle considère que la liaison avec le sink audio est perdue. Dans ce cas, le hub redirige l'audio vers une autre sortie.
Figure 1 Topologie pour associer des appareils auditifs à des appareils mobiles Android à l'aide de CoC via BLE
Lorsque la centrale ne diffuse pas de données audio vers le périphérique et qu'elle peut maintenir une connexion BLE, elle ne doit pas se déconnecter du périphérique. Le maintien de la connexion permet la communication de données avec le serveur GATT situé sur le périphérique.
Lors de l'association et de la connexion d'appareils auditifs, la centrale doit:
- Gardez une trace des périphériques gauche et droit les plus récents associés.
- Supposons que les périphériques soient utilisés si une association valide existe. Le contrôleur central doit tenter de se connecter ou de se reconnecter à l'appareil associé lorsque la connexion est perdue.
- Supposons que les périphériques ne soient plus utilisés si une association est supprimée.
Dans les cas ci-dessus, le couplage fait référence à l'action d'enregistrement d'un ensemble d'appareils auditifs avec un UUID donné et des indicateurs gauche/droite dans l'OS, et non au processus d'association Bluetooth.
Configuration requise
Pour implémenter correctement le CoC afin d'offrir une bonne expérience utilisateur, les systèmes Bluetooth des appareils centraux et périphériques doivent:
- implémenter un contrôleur BT 4.2 ou version ultérieure conforme. Nous vous recommandons vivement d'utiliser les connexions sécurisées LE.
- La centrale doit prendre en charge au moins deux liaisons LE simultanées avec des paramètres tels que décrits dans la section Format et synchronisation des paquets audio.
- Le périphérique doit prendre en charge au moins un lien LE avec les paramètres décrits dans la section Format et synchronisation des paquets audio.
- disposent d'un contrôle de flux basé sur les crédits LE [BT Vol 3, Part A, Sec 10.1]. Les appareils doivent prendre en charge une taille de MTU et de MPS d'au moins 167 octets sur le CoC et être en mesure de mettre en mémoire tampon jusqu'à huit paquets.
- avoir une extension de longueur de données LE [BT Vol 6, Part B, Sec 5.1.9] avec une charge utile d'au moins 167 octets.
-
L'appareil central doit prendre en charge la commande de mise à jour de la connexion HCI LE et respecter les paramètres
maximum_CE_Lengthetminimum_CE_Lengthnon nuls. - Le central doit maintenir le débit de données pour deux connexions LE COC à deux périphériques différents avec les intervalles de connexion et les tailles de charge utile au format et au calendrier des paquets audio.
-
Le périphérique doit définir les paramètres
MaxRxOctetsetMaxRxTimedans les tramesLL_LENGTH_REQouLL_LENGTH_RSPsur les valeurs les plus faibles requises pour ces spécifications. Cela permet au système central d'optimiser son planificateur de temps lors du calcul du temps nécessaire pour recevoir un frame.
Il est fortement recommandé que le central et le périphérique prennent en charge la PHY 2 Mo, comme spécifié dans la spécification BT 5.0. Le central doit prendre en charge des liaisons audio d'au moins 64 kbit/s sur les PHY 1 M et 2 M. La PHY longue portée BLE ne doit pas être utilisée.
Le CoC utilise les mécanismes Bluetooth standards pour le chiffrement de la couche liaison de données et le saut de fréquence.
Services GATT ASHA
Un périphérique doit implémenter le service de serveur GATT ASHA (Audio Streaming for Hearing Aid) décrit ci-dessous. Le périphérique doit annoncer ce service en mode découverte général pour permettre au dispositif central de reconnaître un collecteur audio. Toutes les opérations de streaming audio LE doivent nécessiter un chiffrement. Le streaming audio BLE se compose des caractéristiques suivantes:
| Caractéristique | Propriétés | Description |
|---|---|---|
| ReadOnlyProperties | Lire | Consultez ReadOnlyProperties. |
| AudioControlPoint | Écrire et Écrire sans réponse | Point de contrôle du flux audio. Consultez AudioControlPoint. |
| AudioStatusPoint | Lire/Notifier | Champ du rapport d'état du point de contrôle audio. Consultez AudioStatusPoint. |
| Volume | Écrire sans réponse | Octet compris entre -128 et 0 indiquant le niveau d'atténuation à appliquer au signal audio en streaming, compris entre -48 dB et 0 dB. La valeur -128 doit être interprétée comme une mise en sourdine complète, c'est-à-dire que le niveau de volume le plus bas sans mise en sourdine est -127, ce qui équivaut à une atténuation de -47,625 dB. Au réglage 0, un son sinusoïdal rail à rail diffusé doit représenter un équivalent d'entrée de 100 dBSPL sur l'appareil auditif. Le central doit diffuser en pleine échelle nominale et utiliser cette variable pour définir le niveau de présentation souhaité dans le périphérique. |
| LE_PSM_OUT | Lire | PSM à utiliser pour connecter le canal audio. À choisir dans la plage dynamique [BT Vol 3, Part A, Sec 4.22] |
Les UUID attribués au service et aux caractéristiques:
UUID du service: {0xFDF0}
| Caractéristique | UUID |
|---|---|
| ReadOnlyProperties | {6333651e-c481-4a3e-9169-7c902aad37bb} |
| AudioControlPoint | {f0d4de7e-4a88-476c-9d9f-1937b0996cc0} |
| AudioStatus | {38663f1a-e711-4cac-b641-326b56404837} |
| Volume | {00e4ca9e-ab14-41e4-8823-f9e70c7e91df} |
| LE_PSM_OUT | {2d410339-82b6-42aa-b34e-e2e01df8cc1a} |
En plus du service GATT ASHA, le périphérique doit également implémenter le service d'informations sur l'appareil pour permettre au central de détecter les noms du fabricant et de l'appareil du périphérique.
ReadOnlyProperties
Les valeurs ReadOnlyProperties sont les suivantes:
| Octet | Description |
|---|---|
| 0 | Version : doit être 0x01 |
| 1 | Consultez DeviceCapabilities. |
| 2-9 | Voir HiSyncId. |
| 10 | Consultez FeatureMap. |
| 11-12 | RenderDelay. Il s'agit du temps, en millisecondes, entre le moment où le périphérique reçoit un frame audio et le moment où il effectue le rendu de la sortie. Ces octets peuvent être utilisés pour retarder une vidéo afin de la synchroniser avec l'audio. |
| 13-14 | Réservé pour une utilisation ultérieure. Initialisez à zéro. |
| 15-16 | ID de codec compatibles. Il s'agit d'un masque de bits des ID de codec compatibles. Un 1 à un emplacement de bit correspond à un codec compatible. Par exemple, 0x0002 indique que G.722 à 16 kHz est compatible. Tous les autres bits doivent être définis sur 0. |
DeviceCapabilities
| Bit | Description |
|---|---|
| 0 | Côté de l'appareil (0: gauche, 1: droite) |
| 1 | Indique si l'appareil est autonome et reçoit des données mono ou s'il fait partie d'un ensemble (0: mono, 1: stéréo) |
| 2 | L'appareil est compatible avec le CSIS (0: non compatible, 1: compatible) |
| 3-7 | Réservé (défini sur 0) |
HiSyncID
Ce champ doit être unique pour tous les appareils binaurals, mais il doit être identique pour les ensembles gauche et droit.
| Octet | Description |
|---|---|
| 0-1 | ID du fabricant. Il s'agit des identifiants d'entreprise attribués par BTSIG. |
| 2-7 | Identifiant unique identifiant l'ensemble d'appareils auditifs. Cet ID doit être identique pour le périphérique de gauche et celui de droite. |
FeatureMap
| Bit | Description |
|---|---|
| 0 | Streaming de la sortie audio du codec LE COC compatible (oui/non). |
| 1-7 | Réservé (défini sur 0). |
ID de codec
Si le bit est défini, ce codec particulier est compatible.
| ID / Numéro de bit | Codec et fréquence d'échantillonnage | Débit requis | Temps de rendu | Obligatoire sur le central (C) ou le périphérique (P) |
|---|---|---|---|---|
| 0 | Réservée | Réservée | Réservée | Réservée |
| 1 | G.722 à 16 kHz | 64 kbit/s | Variable | C et P |
|
Les valeurs 2 à 15 sont réservées. 0 est également réservé. |
||||
AudioControlPoint
Ce point de contrôle ne peut pas être utilisé lorsque le CoC de l'UE est fermé. Pour en savoir plus, consultez la section Démarrer et arrêter un flux audio.
| Code opération | Arguments | Sous-procédure GATT | Description |
|---|---|---|---|
1 «Start» |
|
Écrivez avec réponse et attendez une notification d'état supplémentaire via la caractéristique AudioStatusPoint. |
Indique au périphérique de réinitialiser le codec et de démarrer la lecture du frame 0. Le champ "Codec" indique l'ID de codec à utiliser pour cette lecture.
Par exemple, le champ codec est "1" pour G.722 à 16 kHz. Le champ de bits de type audio indique le ou les types audio présents dans le flux :
Le périphérique ne doit pas demander de mises à jour de la connexion avant qu'un opcode «Stop» ait été reçu.
|
2 «Stop» |
Aucune | Écrivez avec réponse et attendez une notification d'état supplémentaire via la caractéristique AudioStatusPoint. | Indique au périphérique de cesser de générer du contenu audio. Une nouvelle séquence de configuration audio doit être lancée après cet arrêt pour afficher à nouveau l'audio. |
3 «Status» |
|
Rédiger sans réponse |
Informe le périphérique connecté qu'une mise à jour de l'état est disponible sur l'autre périphérique. Le champ associé indique le type de mise à jour :
|
AudioStatusPoint
Champ du rapport d'état du point de contrôle audio
| Opcodes | Description |
|---|---|
| 0 | État OK |
| -1 | Commande inconnue |
| -2 | Paramètres non valides |
Annonces pour le service GATT ASHA
L'UUID du service doit figurer dans le paquet d'annonce. Dans l'annonce ou le frame de réponse à l'analyse, les périphériques doivent disposer de données de service:
| Décalage d'octet | Nom | Description |
|---|---|---|
| 0 | Durée de l'annonce | >= 0x09 |
| 1 | Type d'annonce | 0x16 (données de service - UUID 16 bits) |
| Entre 2 et 3 | UUID du service |
0xFDF0 (ordre octets petit à gauche) Remarque:Il s'agit d'un ID temporaire. |
| 4 | Version du protocole | 0x01 |
| 5 | Capacité |
|
| 6-9 | HiSyncID tronqué | Quatre octets les plus significatifs du HiSyncId. Ces octets doivent être la partie la plus aléatoire de l'ID. |
Les périphériques doivent avoir un type de données Nom local complet qui indique le nom de l'appareil auditif. Ce nom sera utilisé dans l'interface utilisateur de l'appareil mobile afin que l'utilisateur puisse sélectionner le bon appareil. Le nom ne doit pas indiquer le canal gauche ou droit, car ces informations sont fournies dans DeviceCapabilities.
Si les périphériques placent le nom et les types de données de service ASHA dans le même type de trame (ADV ou SCAN RESP), les deux types de données ("Nom local complet" et "Données de service pour le service ASHA") doivent apparaître dans la même trame. Cela permet au lecteur de l'appareil mobile d'obtenir les deux données dans le même résultat de numérisation.
Lors de l'association initiale, il est important que les périphériques diffusent des annonces à une vitesse suffisamment élevée pour que l'appareil mobile puisse les découvrir rapidement et s'y associer.
Synchroniser les périphériques gauche et droit
Pour fonctionner avec le Bluetooth sur les appareils mobiles Android, les périphériques sont chargés de s'assurer qu'ils sont synchronisés. La lecture sur les périphériques périphériques gauche et droit doit être synchronisée dans le temps. Les deux périphériques doivent lire les échantillons audio de la source en même temps.
Les périphériques peuvent synchroniser leur temps à l'aide d'un numéro de séquence ajouté au début de chaque paquet de la charge utile audio. Le contrôleur central garantit que les paquets audio destinés à être lus en même temps sur chaque périphérique ont le même numéro de séquence. Le numéro de séquence augmente d'une unité après chaque paquet audio. Chaque numéro de séquence est de 8 bits de long. Les numéros de séquence se répètent donc après 256 paquets audio. Étant donné que la taille et le taux d'échantillonnage de chaque paquet audio sont fixes pour chaque connexion, les deux périphériques peuvent déduire la durée de lecture relative. Pour en savoir plus sur le paquet audio, consultez la section Format et synchronisation des paquets audio.
Le système central fournit des déclencheurs aux appareils binauraux lorsque la synchronisation peut être nécessaire. Ces déclencheurs informent chaque périphérique de l'état de son appareil périphérique associé chaque fois qu'une opération peut affecter la synchronisation. Les déclencheurs sont les suivants:
-
Dans la commande
«Start»d'AudioControlPoint, l'état de connexion actuel de l'autre côté des appareils binaurals est indiqué. -
Chaque fois qu'une opération de connexion, de déconnexion ou de mise à jour des paramètres de connexion est effectuée sur un périphérique, la commande
«Status»d'AudioControlPoint est envoyée à l'autre côté des appareils binaurals.
Format et synchronisation des paquets audio
L'empaquetage des trames audio (blocs d'échantillons) dans des paquets permet à l'instrument d'audition de dériver la synchronisation à partir des ancrages de synchronisation de la couche liaison de données. Pour simplifier l'implémentation:
- Un frame audio doit toujours correspondre à l'intervalle de connexion dans le temps. Par exemple, si l'intervalle de connexion est de 20 ms et que le taux d'échantillonnage est de 16 kHz, le frame audio doit contenir 320 échantillons.
- Les fréquences d'échantillonnage du système sont limitées à des multiples de 8 kHz pour obtenir toujours un nombre entier d'échantillons dans un frame, quel que soit le temps de frame ou l'intervalle de connexion.
- Un octet de séquence doit être ajouté au début des trames audio. L'octet de séquence doit être compté avec un retour à zéro et permettre au périphérique de détecter un décalage de tampon ou un sous-dépassement.
-
Un frame audio doit toujours tenir dans un seul paquet LE. Le frame audio doit être envoyé en tant que paquet L2CAP distinct. La taille de la PDU LL LE doit être:
taille de la charge utile audio + 1 (compteur de séquence) + 6 (4 pour l'en-tête L2CAP, 2 pour la SDU) - Un événement de connexion doit toujours être suffisamment volumineux pour contenir deux paquets audio et deux paquets vides pour qu'un ACK réserve de la bande passante pour les retransmissions. Notez que le paquet audio peut être fragmenté par le contrôleur Bluetooth de la centrale. Le périphérique doit pouvoir recevoir plus de deux paquets audio fragmentés par événement de connexion.
Pour donner une certaine flexibilité au central, la longueur des paquets G.722 n'est pas spécifiée. La longueur des paquets G.722 peut varier en fonction de l'intervalle de connexion défini par le central.
Le format d'octet de sortie G.722 fait référence à la section 1. 4.4 "Multiplexeur" de la Recommandation ITU-T G.722 (09/2012).
Pour tous les codecs compatibles avec un périphérique, celui-ci doit prendre en charge les paramètres de connexion ci-dessous. Voici une liste non exhaustive des configurations que la centrale peut implémenter.
| Codec | Débit | Intervalle de connexion | Longueur CE (PHY 1 M/2 M) | Taille de la charge utile audio |
|---|---|---|---|---|
| G.722 à 16 kHz | 64 kbit/s | 20 ms | 5 000/3 750 µs | 160 octets |
Démarrer et arrêter un flux audio
Avant de démarrer un flux audio, le contrôleur central interroge les périphériques et établit un codec commun. La configuration du flux se poursuit ensuite selon la séquence suivante:
- PSM et, éventuellement, RenderDelay sont lus. Ces valeurs peuvent être mises en cache par le central.
- Le canal L2CAP CoC est ouvert. Le périphérique doit accorder huit crédits au départ.
- Une mise à jour de la connexion est émise pour passer le lien aux paramètres requis pour le codec choisi. La centrale peut effectuer cette mise à jour de la connexion avant la connexion CoC à l'étape précédente.
- L'hôte central et l'hôte périphérique attendent l'événement de fin de la mise à jour.
-
Redémarrez l'encodeur audio et réinitialisez le compteur de séquence de paquets à 0.
Une commande
«Start»avec les paramètres appropriés est émise sur AudioControlPoint. Le contrôleur central attend une notification d'état réussie de la commande«Start»précédente du périphérique avant le streaming. Cette attente permet au périphérique de préparer son pipeline de lecture audio. Lors du streaming audio, l'instance dupliquée doit être disponible à chaque événement de connexion, même si la latence de l'instance dupliquée actuelle peut être non nulle. - Le périphérique prend le premier paquet audio de sa file d'attente interne (numéro de séquence 0) et le lit.
Le central émet la commande "Stop" pour fermer le flux audio. Après cette commande, le périphérique n'a pas besoin d'être disponible à chaque événement de connexion. Pour redémarrer le streaming audio, suivez la séquence ci-dessus en commençant par l'étape 5. Lorsque la centrale ne diffuse pas de contenu audio en streaming, elle doit toujours maintenir une connexion LE pour les services GATT.
Le périphérique ne doit pas envoyer de mise à jour de connexion à la centrale. Pour économiser de l'énergie, la centrale peut envoyer une mise à jour de la connexion au périphérique lorsqu'il ne diffuse pas de contenu audio.