Prise en charge audio des aides auditives à l'aide de Bluetooth LE

Les aides auditives (HA) peuvent avoir une meilleure accessibilité sur les appareils mobiles sous Android en utilisant des canaux L2CAP (CoC) orientés connexion sur Bluetooth Low Energy (BLE). CoC utilise une mémoire tampon élastique de plusieurs paquets audio pour maintenir un flux audio constant, même en présence de perte de paquets. Ce tampon fournit 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 rester aligné avec les spécifications de base, toutes les valeurs multi-octets de cette page doivent être lues en tant que little-endian.

Terminologie

• Central - l'appareil Android qui recherche les publicités via Bluetooth.
• Périphérique - l'appareil auditif qui envoie des paquets publicitaires via Bluetooth.

Topologie du réseau et architecture du système

Lors de l'utilisation du CoC pour les aides auditives, la topologie du réseau suppose un seul central et deux périphériques, un à gauche et un à droite, comme le montre 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 manque, en raison d'un ajustement monaural ou d'une perte de connexion, la centrale mélange les canaux audio gauche et droit et transmet l'audio au périphérique restant. Si le central perd la connexion aux deux périphériques, le central considère que la liaison avec le récepteur audio est perdue. Dans ces cas, la centrale achemine l'audio vers une autre sortie.

Figure 1. Topologie pour appairer les aides auditives avec des appareils mobiles Android utilisant CoC sur BLE

Lorsque le central ne diffuse pas de données audio vers le périphérique et peut maintenir une connexion BLE, le central ne doit pas se déconnecter du périphérique. Le maintien de la connexion permet la communication des données vers le serveur GATT résidant sur le périphérique.

Lors de l'appairage et de la connexion des aides auditives, la centrale doit :

• Gardez une trace des périphériques gauche et droit les plus récents appariés.
• Supposons que les périphériques sont en cours d'utilisation s'il existe un couplage valide. La centrale tentera de se connecter ou de se reconnecter à l'appareil couplé lorsque la connexion est perdue.
• Supposons que les périphériques ne sont plus utilisés si un jumelage est supprimé.

Dans les cas ci-dessus, l' appairage fait référence à l'action d'enregistrer un ensemble d'aides auditives avec un UUID donné et des désignateurs gauche/droite dans le système d'exploitation, et non le processus d'appairage Bluetooth.

Configuration requise

Pour mettre en œuvre correctement le CoC pour une bonne expérience utilisateur, les systèmes Bluetooth dans les appareils centraux et périphériques doivent :

• mettre en œuvre un contrôleur conforme BT 4.2 ou supérieur. LE Secure Connections est fortement recommandé.
• avoir la prise en charge centrale d'au moins 2 liaisons LE simultanées avec les paramètres décrits dans Format et synchronisation des paquets audio .
• avoir le périphérique prenant en charge au moins 1 lien LE avec les paramètres décrits dans le format et la synchronisation des paquets audio .
• avoir 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 MTU et MPS d'au moins 167 octets sur CoC et être en mesure de mettre en mémoire tampon jusqu'à 8 paquets.
• avoir une extension de longueur de données LE [BT Vol 6, Partie B, Sec 5.1.9] avec une charge utile d'au moins 167 octets.
• faire en sorte que l'appareil central prenne en charge la commande de mise à jour de la connexion HCI LE et respecte les paramètres non nuls maximum_CE_Length et minimum_CE_Length .
• demandez à la centrale de maintenir le débit de données pour deux connexions LE CoC vers deux périphériques différents avec les intervalles de connexion et les tailles de charge utile au format et à la synchronisation des paquets audio .
• faire en sorte que le périphérique définisse les paramètres MaxRxOctets et MaxRxTime dans les LL_LENGTH_REQ ou LL_LENGTH_RSP sur les plus petites valeurs requises nécessaires pour ces spécifications. Cela permet au central d'optimiser son ordonnanceur de temps lors du calcul du temps nécessaire pour recevoir une trame.

Il est fortement recommandé que le central et le périphérique prennent en charge 2 Mo PHY comme spécifié dans la spécification BT 5.0. Le central doit prendre en charge les liaisons audio d'au moins 64 kbit/s sur les PHY 1M et 2M. Le BLE longue portée PHY ne doit pas être utilisé.

CoC utilise les mécanismes Bluetooth standard pour le cryptage de la couche de liaison et le saut de fréquence.

Services ASHA GATT

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écouverte général pour permettre au central de reconnaître un récepteur audio. Toutes les opérations de diffusion audio LE nécessitent un cryptage. Le streaming audio BLE comprend les caractéristiques suivantes :

Les UUID attribués au service et ses caractéristiques :

UUID du service : {0xFDF0}

En plus du service ASHA GATT, le périphérique doit également mettre en œuvre le service d'information sur le périphérique pour permettre au central de détecter les noms de fabricant et les noms de périphérique du périphérique.

ReadOnlyPropertiesReadOnlyProperties

ReadOnlyProperties ont les valeurs suivantes :

Capacités de l'appareil

HiSyncID

Ce champ doit être unique pour tous les appareils binauraux mais il doit être le même pour l'ensemble gauche et droit.

FeatureMap

ID de codec

Si le bit est défini, alors ce codec particulier est pris en charge.

AudioControlPoint

Ce point de contrôle ne peut pas être utilisé lorsque le LE CoC est fermé. Voir Démarrage et arrêt d'un flux audio pour la description de la procédure.

AudioStatusPoint

Champ de rapport d'état pour le point de commande audio

Annonces pour ASHA GATT Service

L' UUID du service doit figurer dans le paquet de publicité. Dans l'annonce ou la trame de réponse d'analyse, les périphériques doivent avoir une donnée de service :

Les périphériques doivent avoir un type de données Nom local complet qui indique le nom de l'aide auditive. Ce nom sera utilisé sur 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 puisque ces informations sont fournies dans DeviceCapabilities .

Si les périphériques placent le nom et les types de données du service ASHA dans le même type de trame (ADV ou SCAN RESP), alors les deux types de données ("Complete Local Name" et "Service Data for ASHA service") doivent apparaître dans la même trame. Cela permet au scanner de l'appareil mobile d'obtenir les deux données dans le même résultat d'analyse.

Lors de l'appairage initial, il est important que les périphériques annoncent à un rythme suffisamment rapide pour permettre à l'appareil mobile de découvrir rapidement les périphériques et de s'y lier.

Synchronisation des périphériques gauche et droit

Pour fonctionner avec Bluetooth sur les appareils mobiles Android, les périphériques doivent s'assurer qu'ils sont 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 simultanément les échantillons audio de la source.

Les périphériques peuvent synchroniser leur temps en utilisant un numéro de séquence ajouté au début de chaque paquet de la charge utile audio. La centrale 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 est incrémenté de un après chaque paquet audio. Chaque numéro de séquence a une longueur de 8 bits, de sorte que les numéros de séquence se répètent après 256 paquets audio. Étant donné que chaque taille de paquet audio et chaque fréquence d'échantillonnage sont fixes pour chaque connexion, les deux périphériques peuvent en déduire le temps de lecture relatif. Pour plus d'informations sur le paquet audio, voir Format et synchronisation du paquet audio .

La centrale assiste en fournissant des déclencheurs aux appareils binauraux lorsque la synchronisation peut avoir lieu. Ces déclencheurs informent chaque périphérique de l'état de son périphérique couplé chaque fois qu'il y a une opération qui peut affecter la synchronisation. Les déclencheurs sont :

• Dans le cadre de la commande «Start» d'AudioControlPoint, l'état de connexion actuel de l'autre côté des appareils binauraux est donné.
• Chaque fois qu'il y a une opération de connexion, de déconnexion ou de mise à jour des paramètres de connexion sur un périphérique, la commande «Status» d'AudioControlPoint est envoyée de l'autre côté des appareils binauraux.

Format et synchronisation des paquets audio

Le regroupement de trames audio (blocs d'échantillons) en paquets permet à l'aide auditive de dériver la synchronisation des ancres de synchronisation de la couche de liaison. Pour simplifier la mise en œuvre :

• Une trame audio doit toujours correspondre à l'intervalle de connexion dans le temps. Par exemple, si l'intervalle de connexion est de 20 ms et que la fréquence d'échantillonnage est de 16 kHz, la trame audio doit contenir 320 échantillons.
• Les taux d'échantillonnage dans le système sont limités à des multiples de 8 kHz pour toujours avoir un nombre entier d'échantillons dans une trame, quel que soit le temps de trame ou l'intervalle de connexion.
• Un octet de séquence doit précéder les trames audio. L'octet de séquence doit compter avec bouclage et permettre au périphérique de détecter une non-concordance de tampon ou un dépassement insuffisant.
• Une trame audio doit toujours tenir dans un seul paquet LE. La trame audio doit être envoyée sous la forme d'un paquet L2CAP séparé. La taille de la PDU LE LL doit être :
  taille de la charge utile audio + 1 (compteur de séquence) + 6 (4 pour l'en-tête L2CAP, 2 pour SDU)
• Un événement de connexion doit toujours être suffisamment grand pour contenir 2 paquets audio et 2 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 2 paquets audio fragmentés par événement de connexion.

Pour donner au central une certaine flexibilité, la longueur du paquet G.722 n'est pas spécifiée. La longueur du paquet G.722 peut changer 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 Rec. UIT-T G.722 (09/2012) section 1.4.4 "Multiplexeur"

Pour tous les codecs pris en charge par un périphérique, le périphérique doit prendre en charge les paramètres de connexion ci-dessous. Il s'agit d'une liste non exhaustive des configurations que la centrale peut mettre en œuvre.

Démarrage et arrêt d'un flux audio

Avant de démarrer un flux audio, la centrale interroge les périphériques et établit un codec dénominateur commun. La configuration du flux suit ensuite la séquence suivante :

1. PSM, et éventuellement, RenderDelay est lu. Ces valeurs peuvent être mises en cache par le central.
2. Le canal CoC L2CAP est ouvert - le périphérique accordera initialement 8 crédits.
3. Une mise à jour de connexion est émise pour basculer le lien vers les paramètres requis pour le codec choisi. La centrale peut effectuer cette mise à jour de connexion avant la connexion CoC à l'étape précédente.
4. L'hôte central et l'hôte périphérique attendent l'événement de fin de mise à jour.
5. Redémarrez l'encodeur audio et réinitialisez le nombre de séquences de paquets à 0. Une commande «Start» avec les paramètres pertinents est émise sur l'AudioControlPoint. La centrale attend une notification d'état réussie de la commande «Start» précédente du périphérique avant de diffuser. Cette attente donne au périphérique le temps de préparer son pipeline de lecture audio. Pendant la diffusion audio, la réplique doit être disponible à chaque événement de connexion, même si la latence actuelle de la réplique peut être différente de zéro.
6. Le périphérique prend le premier paquet audio de sa file d'attente interne (numéro de séquence 0) et le lit.

La centrale émet la commande « Stop » pour fermer le flux audio. Après cette commande, le périphérique n'a plus besoin d'être disponible à chaque événement de connexion. Pour redémarrer la diffusion audio, suivez la séquence ci-dessus, à partir de l'étape 5. Lorsque la centrale ne diffuse pas d'audio, elle doit toujours maintenir une connexion LE pour les services GATT.

Le périphérique ne doit pas envoyer de mise à jour de connexion au central. Pour économiser de l'énergie, la centrale peut émettre une mise à jour de connexion vers le périphérique lorsqu'il ne diffuse pas d'audio.