Supporto audio per apparecchi acustici tramite Bluetooth LE

I dispositivi per apparecchi acustici (HA) possono avere una migliore accessibilità sui dispositivi mobili Android utilizzando i canali L2CAP orientati alla connessione (CoC) su Bluetooth Low Energy (BLE). CoC utilizza un buffer elastico di diversi pacchetti audio per mantenere un flusso costante di audio, anche in presenza di perdita di pacchetti. Questo buffer fornisce una qualità audio per gli apparecchi acustici a scapito della latenza.

Il design di CoC fa riferimento alla Bluetooth Core Specification Version 5 (BT). Per rimanere in linea con le specifiche principali, tutti i valori multibyte in questa pagina devono essere letti come little-endian.

Terminologia

  • Centrale : il dispositivo Android che esegue la scansione di annunci pubblicitari tramite Bluetooth.
  • Periferico : l'apparecchio acustico che invia pacchetti pubblicitari tramite Bluetooth.

Topologia di rete e architettura del sistema

Quando si utilizza CoC per gli apparecchi acustici, la topologia di rete presuppone un unico centrale e due periferiche, una sinistra e una destra, come mostrato nella Figura 1 . Il sistema audio Bluetooth vede le periferiche sinistra e destra come un unico dissipatore audio. Se manca una periferica, a causa di un accoppiamento monofonico o di una perdita di connessione, la centrale mescola il canale audio sinistro e destro e trasmette l'audio alla periferica rimanente. Se la centrale perde la connessione ad entrambe le periferiche, la centrale considera perso il collegamento al dissipatore audio. In questi casi, la centrale indirizza l'audio a un'altra uscita.


Figura 1. Topologia per l'associazione di apparecchi acustici con dispositivi mobili Android utilizzando CoC su BLE

Quando la centrale non trasmette dati audio alla periferica e può mantenere una connessione BLE, la centrale non deve disconnettersi dalla periferica. Il mantenimento della connessione consente la comunicazione dei dati al server GATT residente sulla periferica.

Quando si accoppiano e si collegano gli apparecchi acustici, la centrale deve:

  • Tieni traccia delle periferiche sinistra e destra più recenti accoppiate.
  • Si supponga che le periferiche siano in uso se esiste un abbinamento valido. La centrale tenterà di connettersi o riconnettersi con il dispositivo associato quando la connessione viene persa.
  • Si supponga che le periferiche non siano più in uso se viene eliminata un'associazione.

Nei casi precedenti, l' associazione si riferisce all'azione di registrazione di una serie di apparecchi acustici con un determinato UUID e designatori sinistra/destra nel sistema operativo, non il processo di associazione Bluetooth.

Requisiti di sistema

Per implementare correttamente CoC per una buona esperienza utente, i sistemi Bluetooth nei dispositivi centrali e periferici devono:

  • implementare un controller BT 4.2 o superiore conforme. LE Secure Connections è altamente raccomandato.
  • avere il supporto centrale almeno 2 collegamenti LE simultanei con parametri come descritto in Formato e tempi del pacchetto audio .
  • avere la periferica che supporti almeno 1 LE link con i parametri descritti in Formato e tempo del pacchetto audio .
  • avere un controllo del flusso basato sul credito LE [BT Vol 3, Parte A, Sez 10.1]. I dispositivi devono supportare una dimensione MTU e MPS di almeno 167 byte su CoC e essere in grado di memorizzare nel buffer fino a 8 pacchetti.
  • avere un'estensione della lunghezza dei dati LE [BT Vol 6, Parte B, Sez 5.1.9] con un carico utile di almeno 167 byte.
  • fare in modo che il dispositivo centrale supporti il ​​comando di aggiornamento della connessione HCI LE e rispetti i parametri maximum_CE_Length e minimum_CE_Length diversi da zero.
  • fare in modo che la centrale mantenga il throughput dei dati per due connessioni LE CoC a due diverse periferiche con gli intervalli di connessione e le dimensioni del carico utile in formato e temporizzazione del pacchetto audio .
  • fare in modo che la periferica imposti i parametri MaxRxOctets e MaxRxTime nei frame LL_LENGTH_REQ o LL_LENGTH_RSP in modo che siano i valori minimi richiesti necessari per queste specifiche. Ciò consente alla centrale di ottimizzare il proprio time scheduler durante il calcolo della quantità di tempo necessaria per ricevere un frame.

Si consiglia vivamente che la centrale e la periferica supportino 2 MB PHY come specificato nella specifica BT 5.0. La centrale deve supportare collegamenti audio di almeno 64 kbit/s su entrambi i PHY 1M e 2M. Il PHY a lungo raggio BLE non deve essere utilizzato.

CoC utilizza i meccanismi Bluetooth standard per la crittografia del livello di collegamento e il salto di frequenza.

Servizi ASHA GATT

Una periferica deve implementare il servizio server GATT Audio Streaming for Hearing Aid (ASHA) descritto di seguito. La periferica deve pubblicizzare questo servizio quando è in modalità generale rilevabile per consentire alla centrale di riconoscere un sink audio. Qualsiasi operazione di streaming audio LE richiede la crittografia. Lo streaming audio BLE è costituito dalle seguenti caratteristiche:

Caratteristica Proprietà Descrizione
ReadOnlyProperties Leggi Vedere ReadOnlyProperties .
Punto di controllo audio Scrivi e scrivi senza risposta Punto di controllo per il flusso audio. Vedere AudioControlPoint .
AudioStatusPoint Leggi/Notifica Campo del rapporto di stato per il punto di controllo audio. I codici operativi sono:
  • 0 - Stato OK
  • -1 - Comando sconosciuto
  • -2 - Parametri illegali
Volume Scrivi senza risposta Byte compreso tra -128 e 0 che indica la quantità di attenuazione da applicare al segnale audio in streaming, che va da -48 dB a 0 dB. L'impostazione -128 deve essere interpretata come completamente silenziata, ovvero il livello di volume più basso non silenziato è -127 che equivale a un'attenuazione di -47,625 dB. All'impostazione 0, un tono sinusoidale rail-to-rail trasmesso in streaming deve rappresentare un equivalente in ingresso di 100 dBSPL sull'apparecchio acustico. La centrale eseguirà lo streaming a fondo scala nominale e utilizzerà questa variabile per impostare il livello di presentazione desiderato nella periferica.
LE_PSM_OUT Leggi PSM da utilizzare per collegare il canale audio. Da selezionare dalla gamma dinamica [BT Vol 3, Part A, Sec 4.22]

Gli UUID assegnati al servizio e le caratteristiche:

UUID del servizio : {0xFDF0}

Caratteristica UUID
ReadOnlyProperties {6333651e-c481-4a3e-9169-7c902aad37bb}
Punto di controllo audio {f0d4de7e-4a88-476c-9d9f-1937b0996cc0}
Stato Audio {38663f1a-e711-4cac-b641-326b56404837}
Volume {00e4ca9e-ab14-41e4-8823-f9e70c7e91df}
LE_PSM_OUT {2d410339-82b6-42aa-b34e-e2e01df8cc1a}

Oltre al servizio ASHA GATT, la periferica implementa anche il Device Information Service per consentire alla centrale di rilevare i nomi dei produttori e dei dispositivi della periferica.

ReadOnlyProperties

ReadOnlyProperties ha i seguenti valori:

Byte Descrizione
0 Versione - deve essere 0x01
1 Vedere Funzionalità del dispositivo .
2-9 Vedere HiSyncId .
10 Vedi FeatureMap .
11-12 RenderDelay. Questo è il tempo, in millisecondi, da quando la periferica riceve un frame audio fino a quando la periferica esegue il rendering dell'output. Questi byte possono essere utilizzati per ritardare la sincronizzazione di un video con l'audio.
13-14 Riservato per uso futuro. Inizializza a zero.
15-16 ID codec supportati. Questa è una maschera di bit degli ID codec supportati. Una posizione 1 in un bit corrisponde a un codec supportato. Ad esempio, 0x0002 indica che è supportato G.722 a 16 kHz. Tutti gli altri bit devono essere impostati a 0.

Capacità del dispositivo

Morso Descrizione
0 Lato dispositivo (sinistra: 0, destra: 1).
1 Mono (0) / Biauricolare (1). Indica se il dispositivo è autonomo e riceve dati mono o se il dispositivo fa parte di un set.
2-7 Riservato (impostato su 0).

HiSyncID

Questo campo deve essere univoco per tutti i dispositivi binaurali ma deve essere lo stesso per il set sinistro e destro.

Byte Descrizione
0-1 ID del produttore. Sono i Company Identifier assegnati da BTSIG.
2-7 ID univoco che identifica il set di apparecchi acustici. Questo ID deve essere impostato sullo stesso sia sulla periferica sinistra che su quella destra.

Mappa delle caratteristiche

Morso Descrizione
0 Streaming di uscita audio LE CoC supportato (Sì/No).
1-7 Riservato (impostato su 0).

ID codec

Se il bit è impostato, quel particolare codec è il supporto.

ID/numero di bit Codec e frequenza di campionamento Bitrate richiesto Tempo di inquadratura Obbligatorio su centrale (C) o periferica (P)
0 Riservato Riservato Riservato Riservato
1 G.722 a 16 kHz 64 kbit/s Variabile C e P
2-15 sono riservati.
0 è anche riservato.

Punto di controllo audio

Questo punto di controllo non può essere utilizzato quando il LE CoC è chiuso. Vedere Avvio e arresto di un flusso audio per la descrizione della procedura.

Codice operativo argomenti Descrizione
1 «Start»
  • uint8_t codec
  • uint8_t audiotype
  • int8_t volume
  • int8_t otherstate
Indica alla periferica di reimpostare il codec e avviare la riproduzione del fotogramma 0. Il campo codec indica l'ID codec da utilizzare per questa riproduzione. Ad esempio, il campo del codec è "1" per G.722 a 16k Hz.

Il campo del bit del tipo di audio indica il tipo o i tipi di audio presenti nel flusso:
  • 0 - Sconosciuto
  • 1 - Suoneria
  • 2 - Telefonata
  • 3 - Media
Il campo otherstate indica se l'altro lato dei dispositivi binaurali è collegato. Il valore del campo è 1 quando l'altra periferica è collegata, altrimenti il ​​valore è 0.

La periferica non richiederà aggiornamenti di connessione prima che sia stato ricevuto un codice operativo «Stop» .
2 «Stop» Nessuno Indica alla periferica di interrompere il rendering dell'audio. Una nuova sequenza di configurazione dell'audio deve essere avviata dopo questa interruzione per eseguire nuovamente il rendering dell'audio.
3 «Status»
  • uint8_t connected
Informa la periferica collegata che è in corso un aggiornamento dello stato sull'altra periferica. Il campo collegato indica il tipo di aggiornamento:
  • 0 - Altra periferica disconnessa
  • 1 - Altra periferica collegata
  • 2 - Si è verificato un aggiornamento del parametro di connessione LE su una delle connessioni

Annunci per il servizio ASHA GATT

L' UUID del servizio deve trovarsi nel pacchetto dell'annuncio. Sia nell'annuncio che nel frame di risposta alla scansione, le periferiche devono avere un Service Data:

Offset di byte Nome Descrizione
0 Lunghezza d.C >= 0x09
1 Tipo AD 0x16 (dati di servizio - UUID a 16 bit)
2-3 Servizio UUID 0xFDF0 (Little Endian)

Nota: questo è un ID temporaneo.
4 Versione protocollo 0x01
5 Capacità
  • 0 - lato sinistro (0) o destro (1).
  • 1 - dispositivi singoli (0) o doppi (1).
  • 2-7 - riservato. Questi bit devono essere zero.
6-9 HiSyncID troncato Quattro byte meno significativi di HiSyncId . Questi byte dovrebbero essere la parte più casuale dell'ID.

Le periferiche devono avere un tipo di dati Nome locale completo che indichi il nome dell'apparecchio acustico. Questo nome verrà utilizzato sull'interfaccia utente del dispositivo mobile in modo che l'utente possa selezionare il dispositivo corretto. Il nome non deve indicare il canale sinistro o destro poiché queste informazioni sono fornite in DeviceCapabilities .

Se le periferiche inseriscono il nome e i tipi di dati del servizio ASHA nello stesso tipo di frame (ADV o SCAN RESP), i due tipi di dati ("Complete Local Name" e "Service Data for ASHA service") appariranno nello stesso frame. Ciò consente allo scanner del dispositivo mobile di ottenere entrambi i dati nello stesso risultato della scansione.

Durante l'associazione iniziale, è importante che le periferiche pubblicizzino a una velocità sufficientemente veloce da consentire al dispositivo mobile di rilevare rapidamente le periferiche e di collegarle ad esse.

Sincronizzazione dei dispositivi periferici sinistro e destro

Per funzionare con Bluetooth su dispositivi mobili Android, i dispositivi periferici sono responsabili della loro sincronizzazione. La riproduzione sui dispositivi periferici sinistro e destro deve essere sincronizzata nel tempo. Entrambi i dispositivi periferici devono riprodurre contemporaneamente campioni audio dalla sorgente.

I dispositivi periferici possono sincronizzare il proprio tempo utilizzando un numero di sequenza anteposto a ciascun pacchetto del payload audio. La centrale garantisce che i pacchetti audio destinati ad essere riprodotti contemporaneamente su ciascuna periferica abbiano lo stesso numero di sequenza. Il numero di sequenza aumenta di uno dopo ogni pacchetto audio. Ogni numero di sequenza è lungo 8 bit, quindi i numeri di sequenza si ripeteranno dopo 256 pacchetti audio. Poiché ogni dimensione del pacchetto audio e frequenza di campionamento è fissa per ciascuna connessione, le due periferiche possono dedurre il tempo di riproduzione relativo. Per ulteriori informazioni sul pacchetto audio, vedere Formato e tempi del pacchetto audio.

La centrale assiste fornendo trigger ai dispositivi binaurali quando potrebbe essere necessario eseguire la sincronizzazione. Questi trigger informano ciascuna periferica dello stato del dispositivo periferico associato ogni volta che si verifica un'operazione che potrebbe influire sulla sincronizzazione. I trigger sono:

  • Come parte del comando «Start» di AudioControlPoint, viene fornito lo stato di connessione corrente dell'altro lato dei dispositivi binaurali.
  • Ogni volta che c'è un'operazione di connessione, disconnessione o aggiornamento dei parametri di connessione su una periferica, il comando «Status» di AudioControlPoint viene inviato all'altro lato dei dispositivi binaurali.

Formato e tempi del pacchetto audio

L'imballaggio di frame audio (blocchi di campioni) in pacchetti consente all'apparecchio acustico di derivare la temporizzazione dagli ancoraggi di temporizzazione del livello di collegamento. Per semplificare l'implementazione:

  • Un frame audio dovrebbe sempre corrispondere all'intervallo di connessione nel tempo. Ad esempio, se l'intervallo di connessione è 20 ms e la frequenza di campionamento è 16 kHz, il frame audio deve contenere 320 campioni.
  • Le frequenze di campionamento nel sistema sono limitate a multipli di 8kHz per avere sempre un numero intero di campioni in un frame indipendentemente dal tempo del frame o dall'intervallo di connessione.
  • Un byte di sequenza deve anteporre i frame audio. Il byte della sequenza deve essere conteggiato con wrap-around e consentire alla periferica di rilevare la mancata corrispondenza o l'underflow del buffer.
  • Un frame audio deve sempre essere contenuto in un singolo pacchetto LE. Il frame audio deve essere inviato come pacchetto L2CAP separato. La dimensione della PDU LE LL deve essere:
    dimensione del carico utile audio + 1 (contatore sequenza) + 6 (4 per intestazione L2CAP, 2 per SDU)
  • Un evento di connessione dovrebbe sempre essere sufficientemente grande da contenere 2 pacchetti audio e 2 pacchetti vuoti per un ACK per riservare la larghezza di banda per le ritrasmissioni. Si noti che il pacchetto audio potrebbe essere frammentato dal controller Bluetooth della centrale. La periferica deve essere in grado di ricevere più di 2 pacchetti audio frammentati per evento di connessione.

Per dare alla centrale una certa flessibilità, la lunghezza del pacchetto G.722 non è specificata. La lunghezza del pacchetto G.722 può variare in base all'intervallo di connessione impostato dalla centrale.

Il formato dell'ottetto di output G.722 fa riferimento al Rec. ITU-T G.722 (09/2012) sezione 1.4.4 "Multiplexer"

Per tutti i codec supportati da una periferica, la periferica deve supportare i parametri di connessione seguenti. Questo è un elenco non esaustivo di configurazioni che la centrale può implementare.

codec Bitrate Intervallo di connessione Lunghezza CE (1M/2M PHY) Dimensioni del carico utile audio
G.722 a 16 kHz 64 kbit/s 20 ms 5000/3750 us 160 byte

Avvio e arresto di un flusso audio

Prima di avviare un flusso audio, la centrale interroga le periferiche e stabilisce un codec denominatore comune. L'impostazione del flusso procede quindi attraverso la seguente sequenza:

  1. PSM e, facoltativamente, viene letto RenderDelay. Questi valori possono essere memorizzati nella cache dalla centrale.
  2. Viene aperto il canale CoC L2CAP: inizialmente la periferica concederà 8 crediti.
  3. Viene emesso un aggiornamento della connessione per commutare il collegamento ai parametri richiesti per il codec scelto. La centrale può eseguire questo aggiornamento della connessione prima della connessione CoC nel passaggio precedente.
  4. Sia l'host centrale che quello periferico attendono l'evento di aggiornamento completo.
  5. Riavviare l'encoder audio e riportare a 0 il conteggio della sequenza dei pacchetti. Sull'AudioControlPoint viene emesso un comando «Start» con i relativi parametri. La centrale attende la corretta notifica dello stato del precedente comando «Start» dalla periferica prima dello streaming. Questa attesa dà alla periferica il tempo di preparare la sua pipeline di riproduzione audio. Durante lo streaming audio, la replica dovrebbe essere disponibile a ogni evento di connessione anche se la latenza della replica corrente potrebbe essere diversa da zero.
  6. La periferica preleva il primo pacchetto audio dalla sua coda interna (numero di sequenza 0) e lo riproduce.

La centrale emette il comando «Stop» per chiudere il flusso audio. Dopo questo comando, non è necessario che la periferica sia disponibile su ogni evento di connessione. Per riavviare lo streaming audio, seguire la sequenza precedente, partendo dal passaggio 5. Quando la centrale non è in streaming audio, dovrebbe comunque mantenere una connessione LE per i servizi GATT.

La periferica non deve rilasciare un aggiornamento di connessione alla centrale. Per risparmiare energia, la centrale può emettere un aggiornamento della connessione alla periferica quando non è in streaming l'audio.