Les appareils auditifs peuvent bénéficier d'une accessibilité améliorée sur les appareils mobiles Android en utilisant des 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 (BT) Core version 6.0. 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 résidant 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 centraux et périphériques doivent effectuer les opérations suivantes :
- Implémentez un contrôleur BT 4.2 ou version ultérieure conforme. Nous vous recommandons vivement d'utiliser les connexions sécurisées LE.
- Prend en charge au moins deux liens LE simultanés sur le périphérique central avec des paramètres tels que décrits dans Format et timing des paquets audio.
- Prend en charge au moins un lien LE sur le périphérique avec les paramètres décrits dans Format et timing des paquets audio.
- Prend en charge 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.
- Prend en charge une extension de la longueur des données LE [BT Vol 6, Part B, Sec 5.1.9] avec une charge utile d'au moins 167 octets.
-
Assurez-vous que l'appareil central est compatible avec la commande HCI LE Connection Update et qu'il respecte les paramètres
maximum_CE_Lengthetminimum_CE_Lengthnon nuls. - Maintenez le débit de données sur le périphérique central 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.
-
Définissez les paramètres
MaxRxOctetsetMaxRxTimedans les framesLL_LENGTH_REQouLL_LENGTH_RSPsur le périphérique sur 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.
Nous vous recommandons vivement que le périphérique central et le périphérique périphérique soient compatibles avec la couche physique 2M, 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 | Voir 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. À sélectionner dans la plage dynamique [BT Vol 3, Part A, Sec 4.22]. |
Les tableaux suivants décrivent les UUID attribués au service et leurs 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 peut avoir les valeurs suivantes :
| Octet | Description |
|---|---|
| 0 | Version : doit être défini sur 0x01 |
| 1 | Voir DeviceCapabilities. |
| 2-9 | Voir HiSyncId. |
| 10 | Voir 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 de l'identifiant de l'entreprise attribué par le 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. | ||||
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 à l'aide de 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 codec est défini sur "1" pour G.722 à 16 kHz.Le champ de bits du type audio indique les types audio présents dans le flux :
otherstate indique si l'autre côté des appareils binauraux est connecté.
La valeur du champ est 1 lorsque l'autre périphérique est connecté, et 0 dans le cas contraire.
Le périphérique ne doit pas demander de mises à jour de la connexion avant la réception d'un opcode «Stop».
|
2 «Stop» |
Aucun |
Écrivez avec une réponse et attendez une notification d'état supplémentaire à l'aide de 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 de l'annonce ou du scan, les périphériques doivent avoir un type 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 | Tronqué : HiSyncId |
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 est utilisé dans l'interface utilisateur de l'appareil mobile pour que l'utilisateur puisse sélectionner le bon appareil. Le nom ne doit pas indiquer le canal de gauche ou de droite, car cette information est fournie 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 long 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»deAudioControlPoint. -
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»deAudioControlPointest 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 comptabilisé 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. Il s'agit d'une liste partielle 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,
RenderDelaysont 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 exécutée surAudioControlPoint. 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.