Supporto audio per apparecchi acustici tramite Bluetooth LE

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

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

Terminologia

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

Topologia della rete e architettura del sistema

Quando si utilizza CoC per gli apparecchi acustici, la topologia di rete presuppone un unico centro 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 adattamento mono 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 il collegamento con entrambe le periferiche, allora la centrale considera perduto il collegamento con il dissipatore audio. In questi casi, la centrale instrada l'audio verso un'altra uscita.


Figura 1. Topologia per associare gli apparecchi acustici ai 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.
  • Supponiamo che le periferiche siano in uso se esiste un accoppiamento valido. La centrale tenterà di connettersi o riconnettersi con il dispositivo accoppiato quando la connessione viene persa.
  • Supponiamo che le periferiche non siano più in uso se un accoppiamento viene eliminato.

Nei casi precedenti, l'accoppiamento si riferisce all'azione di registrazione di un set di apparecchi acustici con un determinato UUID e identificatori sinistro/destro nel sistema operativo, non al processo di accoppiamento Bluetooth.

Requisiti di sistema

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

  • implementare un controller compatibile con BT 4.2 o versione successiva. LE Secure Connections è altamente raccomandato.
  • avere la centrale che supporti almeno 2 collegamenti LE simultanei con parametri come descritto in Formato e temporizzazione dei pacchetti audio .
  • avere la periferica che supporti almeno 1 collegamento LE con i parametri descritti in Formato e temporizzazione dei pacchetti audio .
  • disporre di un controllo di 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 ed essere in grado di bufferizzare fino a 8 pacchetti.
  • avere un'estensione della lunghezza dei dati LE [BT Vol 6, Parte B, Sec 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 sia conforme ai 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 nel formato e nei tempi dei pacchetti audio .
  • fare in modo che la periferica imposti i parametri MaxRxOctets e MaxRxTime nei frame LL_LENGTH_REQ o LL_LENGTH_RSP sui valori più piccoli richiesti necessari per queste specifiche. Ciò consente alla centrale di ottimizzare il proprio programmatore temporale nel calcolare la quantità di tempo necessaria per ricevere un frame.

Si consiglia vivamente che la centrale e la periferica supportino 2 MB PHY come specificato nelle specifiche BT 5.0. La centrale dovrà 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 dovrà implementare il servizio server GATT Audio Streaming for Hearing Aid (ASHA) descritto di seguito. La periferica pubblicizza questo servizio quando è in modalità generale rilevabile per consentire alla centrale di riconoscere un sink audio. Qualsiasi operazione di streaming audio LE richiederà la crittografia. Lo streaming audio BLE presenta le seguenti caratteristiche:

Caratteristica Proprietà Descrizione
Proprietà di sola lettura Leggere Vedere ReadOnlyProperties .
AudioControlPoint Scrivi e scrivi senza risposta Punto di controllo per il flusso audio. Vedere AudioControlPoint .
AudioStatusPoint Leggi/Notifica Campo del rapporto sullo stato del punto di controllo audio. Vedi AudioStatusPoint
Volume Scrivi senza risposta Byte compreso tra -128 e 0 che indica la quantità di attenuazione da applicare al segnale audio in streaming, compreso tra -48 dB e 0 dB. L'impostazione -128 deve essere interpretata come completamente disattivata, ovvero il livello di volume più basso non disattivato è -127 che equivale a un'attenuazione di -47,625 dB. All'impostazione 0, un segnale sinusoidale trasmesso in streaming rappresenterà un ingresso equivalente a 100 dBPL sull'apparecchio acustico. La centrale trasmetterà lo streaming su scala reale nominale e utilizzerà questa variabile per impostare il livello di presentazione desiderato nella periferica.
LE_PSM_OUT Leggere PSM da utilizzare per collegare il canale audio. Da selezionare dalla gamma dinamica [BT Vol 3, Parte A, Sez 4.22]

Gli UUID assegnati al servizio e le caratteristiche:

UUID del servizio : {0xFDF0}

Caratteristica UUID
Proprietà di sola lettura {6333651e-c481-4a3e-9169-7c902aad37bb}
AudioControlPoint {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 dovrà implementare anche il Device Information Service per consentire alla centrale di rilevare i nomi dei produttori e dei dispositivi della periferica.

Proprietà di sola lettura

ReadOnlyProperties hanno i seguenti valori:

Byte Descrizione
0 Versione: deve essere 0x01
1 Vedere Funzionalità del dispositivo .
2-9 Vedi HiSyncId .
10 Vedere Mappa delle funzionalità .
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 bit corrisponde a un codec supportato. Ad esempio, 0x0002 indica che è supportato G.722 a 16 kHz. Tutti gli altri bit saranno impostati su 0.

Funzionalità del dispositivo

Morso Descrizione
0 Lato dispositivo (0: sinistra, 1: destra)
1 Indica se il dispositivo è autonomo e riceve dati mono o se fa parte di un set (0: mono, 1: binaurale)
2 Il dispositivo supporta CSIS (0: non supportato, 1: supportato)
3-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 gli identificatori aziendali 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.

FeatureMap

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 è supportato.

ID/numero di bit Codec e frequenza di campionamento Velocità in bit richiesta Tempo del fotogramma Obbligatorio su centrale (C) o periferico (P)
0 Riservato Riservato Riservato Riservato
1 G.722 a 16kHz 64 kbit/s Variabile C e P
2-15 sono riservati.
Anche 0 è riservato.

AudioControlPoint

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

Codice operativo argomenti Sottoprocedura GATT Descrizione
1 «Start»
  • uint8_t codec
  • uint8_t audiotype
  • int8_t volume
  • int8_t otherstate
Scrivi con risposta e attendi una notifica di stato aggiuntiva tramite la caratteristica AudioStatusPoint . Indica alla periferica di reimpostare il codec e di avviare la riproduzione del fotogramma 0. Il campo codec indica l'ID del codec da utilizzare per questa riproduzione. Ad esempio, il campo codec è "1" per G.722 a 16k Hz.

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

La periferica non richiederà aggiornamenti di connessione prima che venga ricevuto un opcode «Stop» .
2 «Stop» Nessuno Scrivi con risposta e attendi una notifica di stato aggiuntiva tramite la caratteristica AudioStatusPoint . Indica alla periferica di interrompere il rendering dell'audio. Dopo questa interruzione è necessario avviare una nuova sequenza di configurazione audio per riprodurre nuovamente l'audio.
3 «Status»
  • uint8_t connected
Scrivi senza risposta Informa la periferica collegata che è presente un aggiornamento di stato sull'altra periferica. Il campo connesso indica il tipo di aggiornamento:
  • 0 - Altra periferica disconnessa
  • 1 - Altra periferica collegata
  • 2 - Si è verificato un aggiornamento dei parametri di connessione LE su una delle connessioni

AudioStatusPoint

Campo del rapporto sullo stato del punto di controllo audio

Codici operativi Descrizione
0 Stato OK
-1 Comando sconosciuto
-2 Parametri illegali

Pubblicità per il servizio ASHA GATT

L' UUID del servizio deve essere presente nel pacchetto pubblicitario. Nell'annuncio o nel frame di risposta alla scansione, le periferiche devono avere un dato di servizio:

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

Nota: questo è un ID temporaneo.
4 Versione del protocollo 0x01
5 Capacità
  • 0 - lato sinistro (0) o destro (1).
  • 1 - dispositivi singoli (0) o doppi (1).
  • 2 - il dispositivo supporta CSIS (<0: non supportato, 1: supportato)
  • 3-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 indica il nome dell'apparecchio acustico. Questo nome verrà utilizzato nell'interfaccia utente del dispositivo mobile in modo che l'utente possa selezionare il dispositivo giusto. 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), allora i due tipi di dati ("Nome locale completo" e "Dati di servizio per il servizio ASHA") appariranno nello stesso frame. Ciò consente allo scanner del dispositivo mobile di ottenere entrambi i dati nello stesso risultato della scansione.

Durante l'accoppiamento iniziale, è importante che le periferiche vengano pubblicizzate a una velocità sufficientemente veloce da consentire al dispositivo mobile di rilevarle rapidamente e di collegarsi ad esse.

Sincronizzazione dei dispositivi periferici sinistro e destro

Per funzionare con Bluetooth sui dispositivi mobili Android, i dispositivi periferici hanno la responsabilità di garantire che siano sincronizzati. 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 carico utile 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 ciascun pacchetto audio. Ciascun numero di sequenza è lungo 8 bit, quindi i numeri di sequenza si ripeteranno dopo 256 pacchetti audio. Poiché la dimensione di ciascun pacchetto audio e la frequenza di campionamento sono fisse per ciascuna connessione, le due periferiche possono dedurre il relativo tempo di riproduzione. Per ulteriori informazioni sul pacchetto audio, consulta Formato e tempistica del pacchetto audio .

La centrale assiste fornendo trigger ai dispositivi binaurali quando potrebbe essere necessario effettuare la sincronizzazione. Questi trigger informano ciascuna periferica dello stato del dispositivo periferico associato ogni volta che viene eseguita un'operazione che potrebbe influenzare la sincronizzazione. I trigger sono:

  • Nell'ambito del comando «Start» di AudioControlPoint viene fornito lo stato di connessione attuale dell'altro lato dei dispositivi binaurali.
  • Ogni volta che si verifica 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 temporizzazione dei pacchetti audio

L'impacchettamento di fotogrammi audio (blocchi di campioni) in pacchetti consente all'apparecchio acustico di ricavare il tempo dagli ancoraggi di temporizzazione dello strato 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 conterrà 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 dovrà 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 rientrare in un singolo pacchetto LE. Il frame audio verrà inviato come pacchetto L2CAP separato. La dimensione della PDU LE LL sarà:
    dimensione del payload audio + 1 (contatore di sequenze) + 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 affinché un ACK possa riservare 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 dovrà supportare i parametri di connessione riportati di seguito. Questo è un elenco non esaustivo delle configurazioni che la centrale può implementare.

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

Avvio e interruzione 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. Viene letto PSM e, facoltativamente, RenderDelay. Questi valori possono essere memorizzati nella cache dalla centrale.
  2. Viene aperto il canale CoC L2CAP – la periferica concederà inizialmente 8 crediti.
  3. Viene emesso un aggiornamento della connessione per cambiare 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 completamento dell'aggiornamento.
  5. Riavviare il codificatore audio e reimpostare il conteggio della sequenza dei pacchetti su 0. Su AudioControlPoint viene emesso un comando «Start» con i relativi parametri. La centrale attende una notifica di stato avvenuta con successo del precedente comando «Start» da parte della periferica prima dello streaming. Questa attesa dà alla periferica il tempo di preparare la 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 prende 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 ad ogni evento di connessione. Per riavviare lo streaming audio, seguire la sequenza precedente, partendo dal passaggio 5. Quando la centrale non trasmette audio in streaming, dovrebbe comunque mantenere una connessione LE per i servizi GATT.

La periferica non invierà un aggiornamento di connessione alla centrale. Per risparmiare energia, la centrale può emettere un aggiornamento della connessione alla periferica quando non sta trasmettendo audio in streaming.