Prise en charge audio des aides auditives via Bluetooth LE

Les appareils auditifs (HA) peuvent avoir une accessibilité améliorée sur les appareils mobiles fonctionnant sous Android en utilisant des canaux L2CAP (CoC) orientés connexion sur Bluetooth Low Energy (BLE). CoC utilise un tampon élastique de plusieurs paquets audio pour maintenir un flux audio constant, même en présence de perte de paquets. Ce tampon offre une qualité audio aux appareils auditifs au détriment de la latence.

La conception du CoC fait référence à la version 5 (BT) de la spécification Bluetooth Core . Pour rester aligné sur les spécifications de base, toutes les valeurs multi-octets de cette page doivent être lues en petit-boutiste.

Terminologie

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

Topologie du réseau et architecture du système

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


Figure 1. Topologie pour coupler des aides auditives avec des appareils mobiles Android à l'aide de CoC sur BLE

Lorsque la centrale ne diffuse pas de données audio vers le périphérique et peut maintenir une connexion BLE, la centrale 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 appareils auditifs, la centrale doit :

  • Gardez une trace des périphériques gauche et droit les plus récents couplés.
  • Supposons que les périphériques soient utilisés 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 soient plus utilisés si un couplage est supprimé.

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

Configuration requise

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

  • implémentez un contrôleur compatible BT 4.2 ou supérieur. LE Secure Connections est fortement recommandé.
  • avoir le support central au moins 2 liaisons LE simultanées avec des paramètres tels que décrits dans Format et synchronisation des paquets audio .
  • que le périphérique prenne en charge au moins 1 liaison LE avec les paramètres décrits dans Format et synchronisation des paquets audio .
  • avoir un contrôle de flux basé sur les crédits LE [BT Vol 3, Partie 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'à 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.
  • demandez au périphérique central de prendre en charge la commande de mise à jour de la connexion HCI LE et de respecter les paramètres maximum_CE_Length et minimum_CE_Length non nuls.
  • demandez au central 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 la taille des charges utiles au format et au timing des paquets audio .
  • demandez au périphérique de définir les paramètres MaxRxOctets et MaxRxTime dans les trames LL_LENGTH_REQ ou LL_LENGTH_RSP pour qu'ils soient les plus petites valeurs requises pour ces spécifications. Cela permet à la centrale d'optimiser son planificateur de temps lors du calcul du temps nécessaire pour recevoir une trame.

Il est fortement recommandé que le système central et périphérique prenne en charge 2 Mo de PHY, comme spécifié dans la spécification BT 5.0. La centrale doit prendre en charge les liaisons 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 standard pour le cryptage de la couche de liaison et le saut de fréquence.

Services d'ASHA dans le cadre du GATT

Un périphérique doit mettre en œuvre 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 central de reconnaître un récepteur audio. Toutes les opérations de streaming audio LE doivent nécessiter un cryptage. Le streaming audio BLE comprend les caractéristiques suivantes :

Caractéristique Propriétés Description
Propriétés en lecture seule Lire Voir ReadOnlyProperties .
AudioControlPoint Écrire et écrire sans réponse Point de contrôle pour le flux audio. Voir AudioControlPoint .
AudioStatusPoint Lire/Notifier Champ de rapport d'état pour le point de contrôle audio. Voir AudioStatusPoint
Volume Écrire sans réponse Octet compris entre -128 et 0 indiquant le degré d'atténuation à appliquer au signal audio diffusé, allant de -48 dB à 0 dB. Le réglage -128 doit être interprété comme étant entièrement coupé, c'est-à-dire que le niveau de volume le plus bas non coupé est de -127, ce qui équivaut à une atténuation de -47,625 dB. Au réglage 0, une tonalité sinusoïdale rail à rail diffusée doit représenter un équivalent d'entrée de 100 dBSPL sur l'aide auditive. Le central diffusera à pleine échelle nominale et utilisera 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]

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

UUID du service : {0xFDF0}

Caractéristique UUID
Propriétés en lecture seule {6333651e-c481-4a3e-9169-7c902aad37bb}
AudioControlPoint {f0d4de7e-4a88-476c-9d9f-1937b0996cc0}
Statut audio {38663f1a-e711-4cac-b641-326b56404837}
Volume {00e4ca9e-ab14-41e4-8823-f9e70c7e91df}
LE_PSM_OUT {2d410339-82b6-42aa-b34e-e2e01df8cc1a}

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

Propriétés en lecture seule

ReadOnlyProperties a les valeurs suivantes :

Octet Description
0 Version - doit être 0x01
1 Voir DeviceCapabilities .
2-9 Voir HiSyncId .
dix Voir FeatureMap .
11-12 Délai de rendu. Il s'agit du temps, en millisecondes, entre le moment où le périphérique reçoit une trame audio et le moment où le périphérique restitue 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 future. Initialisez à zéro.
15-16 ID de codec pris en charge. Il s'agit d'un masque de bits des ID de codec pris en charge. Un 1 dans un emplacement binaire correspond à un codec pris en charge. Par exemple, 0x0002 indique que G.722 à 16 kHz est pris en charge. Tous les autres bits doivent être mis à 0.

Capacités de l'appareil

Peu Description
0 Côté appareil (0 : gauche, 1 : droite)
1 Indique si l'appareil est autonome et reçoit des données mono, ou si l'appareil fait partie d'un ensemble (0 : monaural, 1 : binaural)
2 L'appareil prend en charge CSIS (0 : non pris en charge, 1 : pris en charge)
3-7 Réservé (mis à 0)

HiSyncID

Ce champ doit être unique pour tous les appareils binauraux mais il doit être le même pour l'ensemble 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’aides auditives. Cet ID doit être défini sur le même sur le périphérique gauche et droit.

Carte des fonctionnalités

Peu Description
0 Streaming de sortie audio LE CoC pris en charge (Oui/Non).
1-7 Réservé (mis à 0).

ID de codec

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

Numéro d'identification/bit Codec et taux d'échantillonnage Débit requis Temps de trame Obligatoire sur central (C) ou périphérique (P)
0 Réservé Réservé Réservé Réservé
1 G.722 à 16 kHz 64 kbit/s Variable C et P
2 à 15 sont réservés.
0 est également réservé.

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.

Opcode Arguments Sous-procédure du GATT Description
1 «Start»
  • uint8_t codec
  • uint8_t audiotype
  • int8_t volume
  • int8_t otherstate
Écrivez avec réponse et attendez-vous à une notification d'état supplémentaire via la caractéristique AudioStatusPoint . Demande au périphérique de réinitialiser le codec et de démarrer la lecture de l’image 0. Le champ codec indique l’ID du codec à utiliser pour cette lecture. Par exemple, le champ du codec est « 1 » pour G.722 à 16 kHz.

Le champ bit de type audio indique le(s) type(s) audio présent(s) dans le flux :
  • 0 - Inconnu
  • 1 - Sonnerie
  • 2 - Appel téléphonique
  • 3 - Médias
Le champ 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é, sinon la valeur est 0.

Le périphérique ne doit pas demander de mises à jour de connexion avant la réception d'un opcode «Stop» .
2 «Stop» Aucun Écrivez avec réponse et attendez-vous à une notification d'état supplémentaire via la caractéristique AudioStatusPoint . Demande au périphérique d’arrêter le rendu audio. Une nouvelle séquence de configuration audio doit être lancée après cet arrêt afin de restituer à nouveau l'audio.
3 «Status»
  • uint8_t connected
Écrire sans réponse Informe le périphérique connecté qu'il y a une mise à jour de l'état sur l'autre périphérique. Le champ connecté indique le type de mise à jour :
  • 0 - Autre périphérique déconnecté
  • 1 - Autre périphérique connecté
  • 2 - Une mise à jour des paramètres de connexion LE s'est produite sur l'une ou l'autre des connexions.

AudioStatusPoint

Champ de rapport d'état pour le point de contrôle audio

Codes opérationnels Description
0 Statut OK
-1 Commande inconnue
-2 Paramètres illégaux

Publicités pour le service ASHA GATT

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

Décalage d'octet Nom Description
0 Longueur AD >= 0x09
1 Type d'annonce 0x16 (Données de service - UUID 16 bits)
2-3 UUID du service 0xFDF0 (petit-boutiste)

Remarque : Il s'agit d'un identifiant temporaire.
4 Version du protocole 0x01
5 Aptitude
  • 0 - côté gauche (0) ou droit (1)
  • 1 - appareils simples (0) ou doubles (1).
  • 2 - l'appareil prend en charge CSIS (<0 : non pris en charge, 1 : pris en charge)
  • 3-7 - réservé. Ces bits doivent être nuls.
6-9 HiSyncID tronqué Quatre octets de poids faible du HiSyncId . Ces octets doivent constituer 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'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 cette information est fournie dans DeviceCapabilities .

Si les périphériques mettent 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 (« Nom local complet » et « Données de service pour le service ASHA ») 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 du couplage initial, il est important que les périphériques fassent de la publicité à un rythme suffisamment rapide pour permettre à l'appareil mobile de découvrir rapidement les périphériques et de s'y connecter.

Synchronisation des périphériques gauche et droit

Pour fonctionner avec Bluetooth sur les appareils mobiles Android, les périphériques sont chargés de garantir leur synchronisation. 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 des échantillons audio de la source.

Les périphériques peuvent synchroniser leur heure 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 incrémente de un après chaque paquet audio. Chaque numéro de séquence a une longueur de 8 bits, donc les numéros de séquence se répéteront après 256 paquets audio. Étant donné que la taille de chaque paquet audio et la 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, consultez Format et synchronisation du paquet audio .

La centrale aide en fournissant des déclencheurs aux appareils binauraux lorsque la synchronisation doit 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 susceptible d'affecter la synchronisation. Les déclencheurs sont :

  • Dans le cadre de la commande «Start» d'AudioControlPoint, l'état actuel de la connexion de l'autre côté des appareils binauraux est indiqué.
  • A 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 à l'autre côté des appareils binauraux.

Format et timing des paquets audio

Le regroupement de trames audio (blocs d'échantillons) en paquets permet à l'aide auditive de dériver la synchronisation à partir 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 la fréquence d'échantillonnage de 16 kHz, la trame audio doit contenir 320 échantillons.
  • Les fréquences d'échantillonnage dans le système sont limitées à des multiples de 8 kHz pour toujours avoir un nombre entier d'échantillons dans une trame, quel que soit la durée de la 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 inadéquation 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 forme de paquet L2CAP distinct. 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 la bande passante pour les retransmissions. A noter que le paquet audio peut être fragmenté par le contrôleur Bluetooth de la centrale. Le périphérique doit être capable de recevoir plus de 2 paquets audio fragmentés par événement de connexion.

Pour donner une certaine flexibilité au central, 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. ITU-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 de configurations que la centrale peut mettre en œuvre.

Codec Débit Intervalle de connexion Longueur CE (1M/2M PHY) Taille de la charge utile audio
G.722 à 16 kHz 64 kbit/s 20 ms 5000/3750 nous 160 octets

Démarrer et arrêter 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 passe ensuite par la séquence suivante :

  1. PSM et éventuellement RenderDelay sont lus. Ces valeurs peuvent être mises en cache par la centrale.
  2. Le canal CoC L2CAP est ouvert – le périphérique doit initialement accorder 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 préalable «Start» 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 le streaming 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 pas besoin d'être disponible à chaque événement de connexion. Pour redémarrer la diffusion audio, suivez la séquence ci-dessus, en commençant à l'étape 5. Lorsque la centrale ne diffuse pas d'audio, elle doit toujours maintenir une connexion LE pour les services du GATT.

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