Les prothèses auditives peuvent améliorer l'accessibilité Appareils mobiles Android utilisant le protocole L2CAP orienté connexion canaux (CoC) sur Bluetooth à basse consommation (BLE). Le CoC utilise une couche élastique de plusieurs paquets audio afin de maintenir un flux continu de données audio, en présence de perte de paquets. Ce tampon fournit une qualité audio appareils auditifs au détriment de la latence.
Le design du CoC fait référence Bluetooth Spécification de base version 5 (BT). Pour respecter les spécifications de base, tous les enregistrements les valeurs de cette page doivent être interprétées comme small-endian.
Terminologie
- Central : appareil Android qui recherche des publicités via le Bluetooth.
- Périphérique : l'appareil auditif qui envoie des paquets publicitaires via Bluetooth.
Topologie du réseau et architecture du système
Lorsque vous utilisez le CoC pour des appareils auditifs, la topologie du réseau suppose qu'un seul central et deux périphériques, l'un à gauche et l'autre à droite, comme on peut le voir dans Figure 1 : Le système audio Bluetooth affiche la partie gauche et les périphériques droits comme un seul récepteur audio. Si un périphérique est en raison d'un ajustement monauraux ou d'une perte de connexion, le canal central mélange les canaux audio gauche et droit et transmet l'audio vers le périphérique restant. Si le central perd la connexion aux deux périphériques, le central prend en compte le lien vers le récepteur audio perdu. Dans ce cas, la partie centrale achemine l'audio vers une autre sortie.
Figure 1 : Topologie d'association des appareils auditifs avec
Appareils mobiles Android utilisant le CoC sur BLE
Lorsque le central 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 au serveur GATT résident sur le périphérique.
Lors de l'association et de la connexion des prothèses auditives, la centrale doit:
- Effectuez le suivi des périphériques gauche et droit les plus récents associés.
- Supposons que les périphériques soient utilisés s'il existe une association valide. La le réseau central tente de se connecter ou de s'y reconnecter appareil en cas de perte de connexion.
- En supposant que les périphériques ne sont plus utilisés si une association est supprimée.
Dans les cas ci-dessus, l'association fait référence à l'action enregistrer un ensemble d'appareils auditifs avec un UUID donné et l'indicateur gauche/droit dans le système d'exploitation, et non lors du processus d'association Bluetooth.
Configuration requise
Pour une bonne expérience utilisateur, la technologie Bluetooth les systèmes des périphériques centraux et périphériques doivent:
- implémenter un contrôleur BT 4.2 ou version ultérieure conforme. LE Secure Connections est fortement recommandé.
- prennent en charge au moins deux liaisons LE simultanées avec des paramètres comme décrit dans la section Paquet audio et les codes temporels.
- Le périphérique doit être compatible avec au moins une liaison LE avec les paramètres comme décrit dans la section Paquet audio et les codes temporels.
- un contrôle de flux basé sur le crédit LE [BT Vol 3, Part A, Sec 10.1]. Les appareils doivent accepter une taille de MTU et MPS d'au moins 167 octets sur CoC et pouvoir mettre en mémoire tampon jusqu'à 8 paquets.
- ont 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.
-
faire en sorte que l'appareil central prenne en charge la commande de mise à jour de connexion HCI LE ;
et respecter des
maximum_CE_Lengthnon nulles Paramètresminimum_CE_Length. - la partie centrale maintient le débit de données pour deux connexions LE CoC sur deux différents périphériques avec les intervalles de connexion et la charge utile tailles dans les paquets audio et les codes temporels.
-
configurez le périphérique sur
MaxRxOctetsParamètresMaxRxTimedansLL_LENGTH_REQouLL_LENGTH_RSPframes comme étant les plus petites valeurs requises nécessaires pour ces spécifications. Ainsi, le centre d'optimiser son planificateur de temps lors du calcul de la durée pour recevoir une trame.
Il est fortement recommandé que la console centrale et le périphérique prennent en charge les fichiers PHY de 2 Mo, car spécifié dans la spécification BT 5.0. Le central doit prendre en charge les liaisons audio de d'au moins 64 kbit/s sur les réseaux 1 M et 2 M de PHY. La plage PHY longue portée BLE ne doit pas être utilisée.
CoC utilise les mécanismes Bluetooth standards pour le chiffrement de la couche de liaison et les sauts de fréquence.
Services ASHA GATT
Un périphérique doit implémenter le flux audio pour les appareils auditifs (ASHA) du service de serveur GATT décrit ci-dessous. Le périphérique doit annoncer ce service en mode général visible de reconnaître un récepteur audio. Toute opération de streaming LE Audio nécessite un chiffrement. Le streaming audio BLE est constitué les caractéristiques suivantes:
| Caractéristique | Propriétés | Description |
|---|---|---|
| ReadOnlyProperties | Lire | Consultez ReadOnlyProperties. |
| Point de contrôle audio | Écriture et écriture sans réponse | Point de contrôle du flux audio. Voir AudioControlPoint : |
| Point d'état audio | 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 niveau d'atténuation à appliquer à signal audio diffusé, compris entre -48 dB et 0 dB. Paramètre -128 doit être interprété comme le son le plus coupé, c'est-à-dire le volume le plus faible sans le son. est de -127, ce qui équivaut à une atténuation de -47,625 dB. Au paramètre 0, un tonalité sinusoïdale rail à rail diffusée doit représenter une entrée de 100 dBSPL sur l'appareil auditif. Le central est traité par flux nominal à l'échelle et utilisez 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 Dynamique [BT Vol 3, Part A, Sec 4.22] |
UUID attribués au service et à ses caractéristiques:
UUID du service: {0xFDF0}
| Caractéristique | UUID |
|---|---|
| ReadOnlyProperties | {6333651e-c481-4a3e-9169-7c902aad37bb} |
| Point de contrôle audio | {f0d4de7e-4a88-476c-9d9f-1937b0996cc0} |
| État de l'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 mettre en place le service d'informations sur les appareils les noms du fabricant et les noms des appareils du périphérique.
ReadOnlyProperties
ReadOnlyProperties ont les valeurs suivantes:
| Octet | Description |
|---|---|
| 0 | Version : doit être 0x01 |
| 1 | Consultez la page DeviceCapability. |
| 2-9 | Consultez HiSyncId. |
| 10 | Consultez FeatureMap. |
| 11-12 | RenderDelay. Il s'agit du laps de temps, en millisecondes, à partir du moment où le périphérique reçoit une trame audio jusqu'à ce qu'il restitue la sortie. Ces octets peuvent être utilisés pour retarder une vidéo se synchronisent avec l'audio. |
| 13-14 | Réservé pour une utilisation ultérieure. Initialisez-la à zéro. |
| 15-16 | ID de codec acceptés. Il s'agit d'un masque de bits d'ID de codec compatibles. Un 1 dans un emplacement de bits correspond à un et le codec pris en charge. Par exemple, 0x0002 indique que G.722 à 16 kHz est pris en charge. Tous les autres bits doivent être définis sur 0. |
Fonctionnalités de l'appareil
| Foret | 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 si le l'appareil fait partie d'un ensemble (0: monaural, 1: binaural) |
| 2 | Appareil compatible avec le CSIS (0: non compatible, 1: compatible) |
| 3-7 | Réservé (défini sur 0) |
ID HiSync
Ce champ doit être unique pour tous les périphériques binauraux, mais il doit s'agir du identique pour l'ensemble de gauche et de droite.
| Octet | Description |
|---|---|
| 0-1 | Identifiant du fabricant. Il s'agit Entreprise Identifiants attribués par BTSIG. |
| 2-7 | Identifiant unique de l'ensemble d'appareils auditifs. Vous devez définir cet identifiant au même périphérique sur le périphérique gauche et droit. |
Carte des caractéristiques
| Foret | Description |
|---|---|
| 0 | Sortie audio LE CoC compatible (Oui/Non). |
| 1-7 | Réservé (défini sur 0). |
ID de codec
Si le bit est défini, le codec en question est alors pris en charge.
| Numéro d'identification | Codec et taux d'échantillonnage | Débit requis | Temps de rendu | Obligatoire sur le point central (C) ou le 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 |
|
2 à 15 sont réservés. 0 est également réservé. |
||||
Point de contrôle audio
Ce point de contrôle ne peut pas être utilisé en cas de fermeture de la commande "LE CoC". Voir Le démarrage et d'un flux audio pour la description de la procédure.
| Code d'opération | Arguments | Sous-procédure GATT | Description |
|---|---|---|---|
1 «Start» |
|
Rédigez et attendez une notification d'état supplémentaire via Caractéristique AudioStatusPoint. |
Ordonne au périphérique de réinitialiser le codec et de démarrer le
lors de 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 k Hz. Le champ de type audio indique le ou les types audio présents dans le flux: <ph type="x-smartling-placeholder">
Le périphérique ne doit pas demander de mises à jour de connexion Le code d'opération «Stop» a été reçu.
|
2 «Stop» |
Aucune | Rédigez et attendez une notification d'état supplémentaire via Caractéristique AudioStatusPoint. | Ordonne au périphérique d'arrêter le rendu audio. Nouvelle piste audio de configuration doit être lancée après cet arrêt, pour restituer l'audio. |
3 «Status» |
|
Écrire sans réponse |
Informe le périphérique connecté qu'une mise à jour de l'état est disponible sur le
autre périphérique. Le champ connecté indique le type de mise à jour:
|
Point d'état audio
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 non autorisés |
Annonces pour le service ASHA GATT
L'UUID du service doit se trouver dans le du paquet publicitaire. Soit dans la publicité, soit dans l'analyse une trame de réponse, les périphériques doivent comporter des données de service:
| Décalage des octets | Nom | Description |
|---|---|---|
| 0 | Durée de l'annonce | ≥ 0 x 09 |
| 1 | Type d'annonce | 0 x 16 (données des services – UUID 16 bits) |
| Entre 2 et 3 | UUID du service |
0xFDF0 (little-endian) Remarque:Il s'agit d'un identifiant temporaire. |
| 4 | Version du protocole | 0x01 |
| 5 | Capacité |
|
| 6-9 | HiSyncID tronqué | Les quatre octets les plus significatifs HiSyncId : Ces octets doivent constituer la partie la plus aléatoire de l'ID. |
Les périphériques doivent avoir un nom local complet. type de données indiquant le nom de l'appareil auditif. Ce nom va être utilisée sur l'interface utilisateur de l'appareil mobile afin que l'utilisateur puisse sélectionner le bon appareil. Le nom n'indique pas la partie gauche ou droite car ces informations sont fournies DeviceCapability :
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), puis les deux types de données ("Nom local complet" et "Données des services pour le service ASHA") apparaissent dans le même cadre. Cela permet au scanner d'appareil mobile d'obtenir à la fois des données dans le même résultat d'analyse.
Lors de l'association initiale, il est important que les périphériques diffuser des annonces à un rythme suffisamment rapide pour permettre à l'appareil mobile de s'afficher rapidement. découvrir les périphériques et de s'y associer.
Synchroniser les périphériques gauche et droit
Pour utiliser le Bluetooth sur les appareils mobiles Android et les périphériques sont chargés de s'assurer qu'ils sont synchronisés. La lecture des périphériques de gauche et de droite doivent être synchronisés dans en temps réel. Les deux périphériques doivent lire des échantillons audio à partir du en même temps.
Les appareils périphériques peuvent synchroniser leur heure à l'aide d'une séquence numéro ajouté au début de chaque paquet de la charge utile audio. Le centre garantit que les paquets audio qui doivent être lus en même temps temps sur chaque périphérique ont le même numéro de séquence. La séquence le nombre augmente d'une unité après chaque paquet audio. Chaque séquence le nombre est 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 le taux d'échantillonnage sont fixes pour chaque connexion, les deux périphériques peuvent déduire la valeur relative le temps de lecture. Pour en savoir plus sur le paquet audio, consultez Format des paquets audio et codes temporels.
Le central aide en fournissant des déclencheurs aux périphériques binauraux lorsque la synchronisation peut avoir besoin de se produire. Ces déclencheurs informent chaque périphérique de l'état de son périphérique périphérique appairé chaque fois qu'une opération 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é de la couche binaurale est fournie. -
Chaque fois qu'il y a une connexion,
une déconnexion ou
l'opération de mise à jour du paramètre
de connexion sur un périphérique,
la commande
«Status»d'AudioControlPoint est envoyée de l'autre côté des dispositifs binauraux.
Format et codes temporels des paquets audio
Le fait d'empaqueter des trames audio (blocs d'échantillons) en paquets permet à l'audition les instruments dérivent les codes temporels à partir des ancres temporelles de la couche de liaison. À simplifier l'implémentation:
- 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 le taux d'échantillonnage est 16 kHz, la trame audio contiendra 320 échantillons.
- Les taux d'échantillonnage dans le système sont limités à des multiples de 8 kHz pour toujours un nombre entier d'échantillons dans une trame, quel que soit le temps de rendu ou l'intervalle de connexion.
- Un octet de séquence doit être ajouté au début des trames audio. Octet de séquence doit compter avec la boucle et permettre au périphérique de détecter une incohérence ou une dépassement de capacité de mémoire tampon.
-
Une trame audio doit toujours tenir dans un seul paquet LE. Audio
est envoyée sous forme de paquet L2CAP distinct. Taille de la LE
L'unité de distribution d'alimentation de distribution (LLC) doit être:
taille de la charge utile audio + 1 (compteur de séquence) + 6 (4 pour l'en-tête L2CAP, 2 pour l'en-tête SDU) - Un événement de connexion doit toujours être suffisamment grand pour contenir deux données audio paquets et 2 paquets vides pour un ACK afin de réserver la bande passante les retransmissions. Notez que le paquet audio peut être fragmenté par le contrôleur Bluetooth central. Le périphérique doit pouvoir recevoir plus de 2 paquets audio fragmentés par événement de connexion.
Pour donner au centre de la flexibilité une certaine flexibilité, la longueur du paquet G.722 n'est pas spécifié. La longueur du paquet G.722 peut changer en fonction de la connexion et l'intervalle défini par le nœud central.
Le format d'octet de sortie G.722 fait référence au Réc. ITU-T G.722 (09/2012) Section 1.4.4 "Multiplexeur"
Pour tous les codecs compatibles avec un périphérique, sont compatibles avec les paramètres de connexion ci-dessous. Cette liste n'est pas exhaustive. de configurations que le central peut mettre en œuvre.
| Codec | Débit | Intervalle de connexion | Longueur CE (1 M/2 M PHY) | Taille de la charge utile audio |
|---|---|---|---|---|
| G.722 à 16 kHz | 64 kbit/s | 20 ms | 5 000/3 750 US | 160 octets |
Démarrer et arrêter un flux audio
Avant de démarrer un flux audio, le centre interroge les périphériques et établit un codec à dénominateur commun. Le flux la configuration se déroule ainsi:
- PSM et, éventuellement, RenderDelay sont lus. Ces valeurs peut être mis en cache par le central.
- Le canal L2CAP CoC est ouvert ; le périphérique doit accorder 8 crédits au départ.
- Une mise à jour de la connexion est publiée pour transférer la liaison vers les paramètres requises pour le codec choisi. Le central peut effectuer cette mise à jour de la connexion avant la connexion CoC à l'étape précédente.
- L'hôte central et l'hôte périphérique attendent la mise à jour complet.
-
Redémarrez l'encodeur audio et réinitialisez le nombre de séquences des paquets sur 0.
Une commande
«Start»avec les paramètres appropriés est émis sur l'AudioControlPoint. Le centre attend une notification d'état réussie de la commande«Start»précédente à partir du périphérique avant la diffusion. Cette attente donne au périphérique de préparer son pipeline de lecture audio. Pendant le streaming audio, l'instance répliquée doit être disponible à chaque événement de connexion, même si la connexion la latence de l'instance répliquée 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 la lit.
Le central émet la commande «Stop» pour fermer le flux audio. Après cette commande, il n'est pas nécessaire que le périphérique soit disponible de connexion. Pour relancer la diffusion audio, répétez la séquence ci-dessus, en commençant de l'étape 5. Lorsque le centre n'est pas en streaming, il devrait tout de même conserver une connexion LE pour GATT services.
Le périphérique ne doit pas émettre de mise à jour de la connexion vers le centre. Pour économiser l'énergie, le central peut mettre à jour la connexion au périphérique quand il ne diffuse pas de contenu audio.