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 :

Caractéristique Propriétés La description
ReadOnlyPropertiesReadOnlyProperties Lis 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. Les opcodes sont :
  • 0 - État OK
  • -1 - Commande inconnue
  • -2 - Paramètres illégaux
Le volume Ecrire sans réponse Octet entre -128 et 0 indiquant la quantité d'atténuation à appliquer au signal audio diffusé, allant de -48 dB à 0 dB. Le réglage -128 doit être interprété comme complètement coupé, c'est-à-dire que le niveau de volume non coupé le plus bas est -127, ce qui équivaut à une atténuation de -47,625 dB. Au réglage 0, une tonalité sinusoïdale rail à rail doit représenter une entrée équivalente à 100 dBSPL sur l'aide auditive. 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 Lis 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 ses caractéristiques :

UUID du service : {0xFDF0}

Caractéristique UUID
ReadOnlyPropertiesReadOnlyProperties {6333651e-c481-4a3e-9169-7c902aad37bb}
AudioControlPoint {f0d4de7e-4a88-476c-9d9f-1937b0996cc0}
ÉtatAudio {38663f1a-e711-4cac-b641-326b56404837}
Le 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 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 :

Octet La 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 celui où le périphérique restitue la sortie. Ces octets peuvent être utilisés pour retarder une vidéo afin qu'elle se synchronise avec l'audio.
13-14 Réservé pour une utilisation future. Initialiser à zéros.
15-16 ID de codec pris en charge . Il s'agit d'un masque binaire 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

Bit La description
0 Côté appareil (Gauche : 0, Droite : 1).
1 Monaural (0) / Binaural (1). Indique si l'appareil est autonome et reçoit des données mono ou si l'appareil fait partie d'un ensemble.
2-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 La 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'aides auditives. Cet identifiant doit être identique sur les périphériques gauche et droit.

FeatureMap

Bit La 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.

ID / Numéro de bit Codec et fréquence 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.

Code d'opération Arguments La description
1 «Start»
  • uint8_t codec
  • uint8_t audiotype
  • int8_t volume
  • int8_t otherstate
Ordonne 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 de codec à utiliser pour cette lecture. Par exemple, le champ codec est "1" pour G.722 à 16k Hz.

Le champ de bits de type audio indique le ou les types audio présents 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 dispositifs 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 qu'un opcode «Stop» n'ait été reçu.
2 «Stop» Aucun Ordonne 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
Informe le périphérique connecté qu'il y a une mise à jour d'é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

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 :

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

Remarque : Il s'agit d'un ID temporaire.
4 Version du protocole 0x01
5 Aptitude
  • 0 - côté gauche (0) ou droit (1)
  • 1 - appareils simples (0) ou doubles (1).
  • 2-7 - réservé. Ces bits doivent être nuls.
6-9 HiSyncID tronqué Quatre octets les moins 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 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.

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 millisecondes 5000/3750 nous 160 octets

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.