Les appareils auditifs (AA) peuvent bénéficier d'une accessibilité améliorée sur les appareils mobiles Android grâce à l'utilisation de canaux L2CAP orientés connexion (CoC) via Bluetooth à basse consommation (BLE). CoC utilise un tampon élastique de plusieurs paquets audio pour maintenir un flux audio stable, même en cas de perte de paquets. Cette mémoire 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 Bluetooth Core Version 5 (BT). Pour respecter les spécifications de base, toutes les valeurs multi-octets de cette page doivent être lues en little-endian.
Terminologie
- central
- Appareil Android qui recherche les annonces via Bluetooth.
- périphérique
- Appareil auditif qui envoie des paquets publicitaires via Bluetooth.
Topologie du réseau et architecture du système
Lorsque vous utilisez CoC pour les appareils auditifs, la topologie du 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 récepteur audio. Si un périphérique est manquant en raison d'un ajustement monaural ou d'une perte de connexion, le périphérique central mixe les canaux audio gauche et droit, puis transmet l'audio au périphérique restant. Si le périphérique central perd la connexion aux deux périphériques, il considère que la connexion au récepteur audio est perdue. Dans ce cas, le hub central redirige l'audio vers une autre sortie.
Figure 1. Topologie pour associer des appareils auditifs à des appareils mobiles Android à l'aide de CoC sur BLE.
Lorsque le périphérique central ne diffuse pas de données audio vers le périphérique et peut maintenir une connexion BLE, il 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, le hub doit :
- Gardez une trace des périphériques gauche et droit les plus récemment associés.
- Considérez que les périphériques sont utilisés si un appairage valide existe. Le central doit tenter de se connecter ou de se reconnecter à l'appareil associé lorsque la connexion est perdue.
- Partez du principe que les périphériques ne sont plus utilisés si une association est supprimée.
Dans les cas ci-dessus, le terme association fait référence à l'action d'enregistrer un ensemble d'appareils auditifs avec un UUID et des désignations gauche/droite donnés dans l'OS, et non au processus d'association Bluetooth.
Configuration requise
Pour implémenter correctement le CoC et offrir une bonne expérience utilisateur, les systèmes Bluetooth des appareils central et périphérique 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.
- Le périphérique central doit disposer d'au moins deux liens LE simultanés avec les paramètres décrits dans Format et timing des paquets audio.
- Le périphérique doit accepter au moins un lien LE avec les paramètres décrits dans Format et timing des paquets audio.
- avoir un contrôle du flux basé sur le crédit LE [BT Vol 3, Part A, Sec 10.1]. Les appareils doivent prendre en charge une taille MTU et MPS d'au moins 167 octets sur CoC et être capables 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 être compatible avec la commande HCI LE Connection Update et respecter les paramètres
maximum_CE_Lengthetminimum_CE_Lengthnon nuls. - Le périphérique 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 dans Format et timing des paquets audio.
-
Le périphérique doit définir les paramètres
MaxRxOctetsetMaxRxTimedans les tramesLL_LENGTH_REQouLL_LENGTH_RSPsur les valeurs minimales requises pour ces spécifications. Cela permet au centre d'optimiser son planificateur de temps lorsqu'il calcule le temps nécessaire pour recevoir un frame.
Il est fortement recommandé que le périphérique central et le périphérique périphérique soient compatibles avec le PHY de 2 Mo, comme spécifié dans la spécification BT 5.0. Le périphérique central doit être compatible avec les liens audio d'au moins 64 kbit/s sur les PHY 1M et 2M. Le PHY longue portée BLE ne doit pas être utilisé.
CoC utilise les mécanismes Bluetooth standards pour le chiffrement de la couche de liaison et le saut de fréquence.
Services GATT ASHA
Un périphérique doit implémenter le service de serveur GATT Audio Streaming for Hearing Aid (ASHA) décrit ci-dessous. Le périphérique doit annoncer ce service lorsqu'il est en mode détectable général pour permettre au périphérique central de reconnaître un récepteur audio. Toutes les opérations de streaming audio LE doivent nécessiter un chiffrement. Le streaming audio BLE comprend les caractéristiques suivantes :
| Caractéristique | Propriétés | Description |
|---|---|---|
| ReadOnlyProperties | Lire | Consultez ReadOnlyProperties. |
| AudioControlPoint | Écrire et Écrire sans réponse | Point de contrôle pour le flux audio. Consultez AudioControlPoint. |
| AudioStatusPoint | Lecture/Notification | Champ de rapport d'état pour le point de contrôle audio. Consultez AudioStatusPoint. |
| Volume | Écrire sans réponse | Byte compris entre -128 et 0 indiquant l'atténuation à appliquer au signal audio diffusé, allant de -48 dB à 0 dB. La valeur -128 doit être interprétée comme un volume complètement coupé.Autrement dit, le niveau de volume non coupé le plus bas est -127, ce qui équivaut à une atténuation de -47,625 dB. À 0, une tonalité sinusoïdale rail-to-rail diffusée doit représenter une entrée équivalente à 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, Partie A, Sec 4.22] |
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 périphérique central de détecter les noms du fabricant et de l'appareil du périphérique.
ReadOnlyProperties
ReadOnlyProperties a les valeurs suivantes :
| Octet | Description |
|---|---|
| 0 | Version : doit être défini sur 0x01 |
| 1 | Consultez DeviceCapabilities. |
| 2-9 | Consultez 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 celui où il affiche le résultat. 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-le à zéro. |
| 15-16 | ID de codec acceptés. Il s'agit d'un masque de bits des ID de codec compatibles. Un "1" dans 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 : monaural, 1 : binaural). |
| 2 | L'appareil est compatible avec CSIS (0 : non compatible, 1 : compatible) |
| 3-7 | Réservé (défini sur 0) |
HiSyncID
Ce champ doit être unique pour tous les appareils binauraux, 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 | ID unique identifiant l'ensemble d'appareils auditifs. Cet ID doit être identique sur les périphériques gauche et droit. |
FeatureMap
| Bit | Description |
|---|---|
| 0 | La diffusion en streaming de la sortie audio LE CoC est-elle prise en charge (Oui/Non) ? |
| 1-7 | Réservé (défini sur 0). |
ID de codec
Si le bit est défini, cela signifie que le codec en question est pris en charge.
| ID/Numéro de bit | Codec et fréquence d'échantillonnage | Débit requis | Temps de rendu | Obligatoire sur le périphérique central (C) ou 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 numéros 2 à 15 sont réservés. 0 est également réservé. |
||||
AudioControlPoint
Ce point de contrôle ne peut pas être utilisé lorsque le CoC LE est fermé. Pour obtenir la description de la procédure, consultez Démarrer et arrêter un flux audio.
| Code opération | Arguments | Sous-procédure GATT | Description |
|---|---|---|---|
1 «Start» |
|
Écrivez avec une 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 commencer la lecture du frame 0. Le champ "codec" indique l'ID de codec à utiliser pour cette lecture.
Par exemple, le champ de 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 la réception d'un opcode «Stop».
|
2 «Stop» |
Aucune | Écrivez avec une réponse et attendez une notification d'état supplémentaire via la caractéristique AudioStatusPoint. | Indique au périphérique d'arrêter de restituer le contenu audio. Une nouvelle séquence de configuration audio doit être lancée après cet arrêt pour que le son soit à nouveau rendu. |
3 «Status» |
|
Écrire sans réponse |
Informe le périphérique connecté qu'une mise à jour de l'état de l'autre périphérique est disponible. Le champ "connected" indique le type de mise à jour :
|
AudioStatusPoint
Champ de rapport d'état pour le point de contrôle audio
| Codes d'opération | Description |
|---|---|
| 0 | État : OK |
| -1 | Commande inconnue |
| -2 | Paramètres illégaux |
Annonces pour le service ASHA GATT
Le UUID du service doit figurer dans le paquet publicitaire. Dans le frame de réponse à l'annonce ou à l'analyse, les périphériques doivent disposer de données de service :
| Décalage d'octets | Nom | Description |
|---|---|---|
| 0 | Durée de l'annonce | >= 0x09 |
| 1 | Type d'annonce | 0x16 (données de service – UUID de 16 bits) |
| Entre 2 et 3 | UUID du service |
0xFDF0 (little-endian) Remarque : Il s'agit d'un ID temporaire. |
| 4 | Version du protocole | 0x01 |
| 5 | Fonctionnalité |
|
| 6-9 | HiSyncID tronqué | Quatre octets les plus significatifs de 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 Complete Local Name (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 les types de données de nom et de service ASHA dans le même type de frame (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 le même frame. Cela permet au lecteur de l'appareil mobile d'obtenir les deux types de données dans le même résultat d'analyse.
Lors de l'association initiale, il est important que les périphériques diffusent des annonces à une fréquence suffisamment élevée pour permettre à l'appareil mobile de les découvrir rapidement et de 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 doivent s'assurer d'être synchronisés. La lecture sur les 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 heure à l'aide d'un numéro de séquence ajouté à chaque paquet de la charge utile audio. Le périphérique central garantit que les paquets audio qui doivent ê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. Les numéros de séquence se répètent donc après 256 paquets audio. Comme la taille et la fréquence 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 Format et timing des paquets audio.
Le hub central aide en fournissant 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 périphérique associé chaque fois qu'une opération peut affecter la synchronisation. Voici les déclencheurs :
-
L'état de connexion actuel de l'autre côté des appareils binauraux est indiqué dans la commande
«Start»d'AudioControlPoint. -
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 binauraux.
Format et timing des paquets audio
L'intégration de trames audio (blocs d'échantillons) dans des paquets permet à l'appareil auditif de déduire le timing à partir des ancres de timing de la couche de liaison. Pour simplifier l'implémentation :
- Un frame audio doit toujours correspondre à l'intervalle de connexion en termes de durée. Par exemple, si l'intervalle de connexion est de 20 ms et que le taux d'échantillonnage est de 16 kHz, la trame audio doit contenir 320 échantillons.
- Les fréquences d'échantillonnage du système sont limitées aux multiples de 8 kHz afin d'avoir toujours un nombre entier d'échantillons dans un frame, quels que soient la durée du frame ou l'intervalle de connexion.
- Un octet de séquence doit précéder les trames audio. Le byte de séquence doit être compté avec retour à zéro et permettre au périphérique de détecter une incohérence ou un sous-dépassement de mémoire tampon.
-
Un frame audio doit toujours tenir dans un seul paquet LE. La trame audio doit être envoyée sous forme de paquet L2CAP distinct. La taille de l'unité de données de protocole (PDU) LE LL doit être la suivante :
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 grand pour contenir deux paquets audio et deux paquets vides pour un ACK afin de réserver 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é à la centrale, 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 "Multiplexer" de la Rec. 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 le centre peut implémenter.
| Codec | Débit | Intervalle de connexion | Longueur de la CE (PHY 1M/2M) | Taille de la charge utile audio |
|---|---|---|---|---|
| G.722 à 16 kHz | 64 kbit/s | 20 ms | 5000/3750 us | 160 octets |
Démarrer et arrêter un flux audio
Avant de démarrer un flux audio, le périphérique central interroge les périphériques et établit un codec de dénominateur commun. La configuration du flux se déroule ensuite selon la séquence suivante :
- Le PSM et, éventuellement, RenderDelay sont lus. Ces valeurs peuvent être mises en cache par le central.
- Le canal L2CAP du 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 de l'étape précédente.
- L'hôte central et l'hôte périphérique attendent l'événement de fin de mise à jour.
-
Redémarrez l'encodeur audio et réinitialisez le nombre de séquences de paquets sur 0.
Une commande
«Start»avec les paramètres appropriés est émise sur AudioControlPoint. La centrale attend une notification d'état de réussite de la commande«Start»précédente du périphérique avant de diffuser le flux. Cette attente permet au périphérique de préparer son pipeline de lecture audio. Lors du streaming audio, la réplique doit être disponible à chaque événement de connexion, même si la latence de la réplique 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 problème central est que la commande Arrêter est envoyée 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 à l'étape 5. Lorsque le périphérique central ne diffuse pas de contenu audio, il doit quand même maintenir une connexion LE pour les services GATT.
Le périphérique ne doit pas envoyer de mise à jour de la connexion au périphérique central. Pour économiser de l'énergie, le périphérique central peut envoyer une mise à jour de la connexion au périphérique, lorsqu'il ne diffuse pas de contenu audio.