L'accessibilità degli apparecchi acustici (HA) può essere migliorata su dispositivi mobili Android utilizzando i canali L2CAP (CoC) orientati alla connessione tramite 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 una qualità audio per gli apparecchi acustici a scapito della latenza.
Il design del CoC fa riferimento alla Bluetooth Core Specification Version 5 (BT). Per mantenere l'allineamento con le specifiche di base, tutti i valori di più byte in questa pagina devono essere letti come little-endian.
Terminologia
- Centrale: il dispositivo Android che esegue la scansione per trovare annunci tramite Bluetooth.
- Periferica: lo strumento acustico che invia i pacchetti di annunci tramite Bluetooth.
Topologia di rete e architettura di sistema
Quando si utilizza il CoC per gli apparecchi acustici, la topologia di rete presuppone un singolo elemento centralizzato e due periferiche, una a sinistra e una a destra, come mostrato nella Figura 1. Il sistema audio Bluetooth vede le periferiche sinistra e destra come un singolo sink audio. Se una periferica è mancante, a causa di un attacco mono o di una perdita di connessione, la unità centralizzata miscela il canale audio sinistro e destro e trasmette l'audio alla periferica rimanente. Se la centrale perde la connessione con entrambe le periferiche, considera perso il collegamento all'uscita audio. In questi casi, la centrale invia l'audio a un'altra uscita.
Figura 1. Topologia per l'accoppiamento degli apparecchi acustici con
dispositivi mobili Android che utilizzano CoC tramite BLE
Quando la centrale non trasmette dati audio in streaming alla periferica e può mantenere una connessione BLE, non deve disconnettersi dalla periferica. Il mantenimento della connessione consente la comunicazione dei dati al server GATT residente sulla periferica.
Durante l'accoppiamento e la connessione delle protesi acustiche, la centrale deve:
- Tieni traccia delle periferiche sinistra e destra accoppiate più recenti.
- Supponiamo che le periferiche siano in uso se esiste un accoppiamento valido. La centralina tenterà di connettersi o ricollegarsi al dispositivo accoppiato quando la connessione viene persa.
- Supponiamo che le periferiche non siano più in uso se un accoppiamento viene eliminato.
Nei casi precedenti, accoppiamento si riferisce all'azione di registrazione di un insieme di apparecchi acustici con un determinato UUID e designatori sinistro/destro nel sistema operativo, non alla procedura di accoppiamento Bluetooth.
Requisiti di sistema
Per implementare correttamente il CoC per un'esperienza utente positiva, i sistemi Bluetooth nei dispositivi centrali e periferici devono:
- Implementare un controller BT 4.2 o versioni successive conforme. Le connessioni sicure LE sono vivamente consigliate.
- supportare almeno 2 link LE simultanei con parametri come descritto in Formato e temporizzazione dei pacchetti audio.
- supportare almeno un link LE con i parametri descritti in Formato e temporizzazione dei pacchetti audio.
- Avere un controllo del flusso basato su credito LE [BT Vol 3, Part A, Sec 10.1]. I dispositivi devono supportare dimensioni MTU e MPS di almeno 167 byte su CoC ed essere in grado di memorizzare in buffer fino a 8 pacchetti.
- avere un'estensione della lunghezza dei dati LE [BT Vol 6, Part B, Sec 5.1.9] con un payload di almeno 167 byte.
-
Il dispositivo centrale deve supportare il comando di aggiornamento della connessione LE HCI
e rispettare i parametri
maximum_CE_Lengtheminimum_CE_Lengthdiversi da zero. - La centrale deve mantenere il throughput dei dati per due connessioni LE CoC a due periferiche diverse con gli intervalli di connessione e le dimensioni del payload in Formato e temporizzazione dei pacchetti audio.
-
La periferica deve impostare i parametri
MaxRxOctetseMaxRxTimenei frameLL_LENGTH_REQoLL_LENGTH_RSPsui valori minimi richiesti necessari per queste specifiche. In questo modo, il Nucleo ottimizza il programmatore del tempo quando calcola il tempo necessario per ricevere un frame.
È vivamente consigliato che il dispositivo centrale e quello periferico supportino PHY da 2 MB come specificato nella specifica BT 5.0. La centrale deve supportare link audio di almeno 64 kbit/s su PHY 1 M e 2 M. Non deve essere utilizzato il protocollo PHY BLE a lungo raggio.
Il CoC utilizza i meccanismi Bluetooth standard per la crittografia del livello di collegamento e per l'hopping di frequenza.
Servizi GATT ASHA
Una periferica deve implementare il servizio del server GATT per lo streaming audio per apparecchi acustici (ASHA) descritto di seguito. La periferica deve pubblicizzare questo servizio quando è in modalità rilevabile generale per consentire alla centralina di riconoscere un sink audio. Qualsiasi operazione di streaming audio LE richiederà la crittografia. Lo streaming audio BLE è costituito dalle seguenti caratteristiche:
| Caratteristica | Proprietà | Descrizione |
|---|---|---|
| ReadOnlyProperties | Letto | Vedi ReadOnlyProperties. |
| AudioControlPoint | Scrivi e Scrivi senza risposta | Punto di controllo per lo stream audio. Vedi AudioControlPoint. |
| AudioStatusPoint | Lettura/notifica | Campo del report sullo stato per il punto di controllo audio. Vedi AudioStatusPoint. |
| Volume | Scrivi senza risposta | Byte compreso tra -128 e 0 che indica l'entità dell'attenuazione da applicare al segnale audio in streaming, che va da -48 dB a 0 dB. L'impostazione -128 deve essere interpretata come audio completamente disattivato, ovvero il livello di volume minimo non disattivato è -127, che equivale a un'attenuazione di -47,625 dB. All'impostazione 0, un tono sinusoidale rail-to-rail in streaming deve rappresentare un livello di ingresso di 100 dBSPL equivalente sull'apparecchio acustico. La centrale deve trasmettere in scala completa nominale e utilizzare questa variabile per impostare il livello di presentazione desiderato nella periferica. |
| LE_PSM_OUT | Letto | Il PSM da utilizzare per collegare il canale audio. Da scegliere dall'intervallo dinamico [BT Vol 3, Part A, Sec 4.22] |
Gli UUID assegnati al servizio e alle caratteristiche:
UUID servizio: {0xFDF0}
| Caratteristica | UUID |
|---|---|
| ReadOnlyProperties | {6333651e-c481-4a3e-9169-7c902aad37bb} |
| AudioControlPoint | {f0d4de7e-4a88-476c-9d9f-1937b0996cc0} |
| AudioStatus | {38663f1a-e711-4cac-b641-326b56404837} |
| Volume | {00e4ca9e-ab14-41e4-8823-f9e70c7e91df} |
| LE_PSM_OUT | {2d410339-82b6-42aa-b34e-e2e01df8cc1a} |
Oltre al servizio GATT ASHA, la periferica deve anche implementare il servizio Device Information Service per consentire alla centrale di rilevare i nomi del produttore e del dispositivo della periferica.
ReadOnlyProperties
ReadOnlyProperties ha i seguenti valori:
| Byte | Descrizione |
|---|---|
| 0 | Versione: deve essere 0x01 |
| 1 | Consulta DeviceCapabilities. |
| 2-9 | Vedi HiSyncId. |
| 10 | Consulta FeatureMap. |
| 11-12 | RenderDelay. Si tratta del tempo, in millisecondi, che intercorre tra il momento in cui la periferica riceve un frame audio e il momento in cui la periferica esegue il rendering dell'output. Questi byte possono essere utilizzati per ritardare un video in modo da sincronizzarlo con l'audio. |
| 13-14 | Riservato per uso futuro. Inizializza con zeri. |
| 15-16 | ID codec supportati. Si tratta di una maschera di bit degli ID codec supportati. Un 1 in una posizione del bit corrisponde a un codec supportato. Ad esempio, 0x0002 indica che G.722 a 16 kHz è supportato. Tutti gli altri bit devono essere impostati su 0. |
DeviceCapabilities
| Bit | Descrizione |
|---|---|
| 0 | Lato del dispositivo (0: sinistro, 1: destro) |
| 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 biauricolari, ma deve essere uguale per l'impostazione sinistra e destra.
| Byte | Descrizione |
|---|---|
| 0-1 | ID del produttore. Si tratta degli identificatori della società assegnati da BTSIG. |
| 2-7 | ID univoco che identifica l'apparecchio acustico impostato. Questo ID deve essere impostato su lo stesso valore sia sulla periferica sinistra sia su quella destra. |
FeatureMap
| Bit | Descrizione |
|---|---|
| 0 | Streaming dell'uscita audio LE CoC supportato (Sì/No). |
| 1-7 | Riservato (impostato su 0). |
ID codec
Se il bit è impostato, significa che quel determinato codec è supportato.
| ID / Numero di bit | Codec e frequenza di campionamento | Velocità in bit richiesta | Durata frame | Obbligatorio su centrali (C) o periferiche (P) |
|---|---|---|---|---|
| 0 | Riservata | Riservata | Riservata | Riservata |
| 1 | G.722 a 16 kHz | 64 kbit/s | Variabile | C e P |
|
2-15 sono riservati. 0 è riservato anche. |
||||
AudioControlPoint
Questo punto di controllo non può essere utilizzato quando il CoC LE è chiuso. Per la descrizione della procedura, consulta Avviare e interrompere un stream audio.
| Opcode | Argomenti | Procedura secondaria GATT | Descrizione |
|---|---|---|---|
1 «Start» |
|
Scrivi con risposta e attendi una notifica di stato aggiuntiva tramite la caratteristica AudioStatusPoint. |
Indica alla periferica di reimpostare il codec e avviare la riproduzione del frame 0. Il campo codec indica l'ID codec da utilizzare
per questa riproduzione.
Ad esempio, il campo codec è "1" per G.722 a 16 KHz. Il campo di bit del tipo di audio indica i tipi di audio presenti nello stream:
La periferica non deve richiedere aggiornamenti di connessione prima che sia stata ricevuta 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. Al termine dell'interruzione, deve essere avviata una nuova sequenza di configurazione audio per eseguire nuovamente il rendering dell'audio. |
3 «Status» |
|
Scrivere senza risposta |
Informa la periferica connessa che è disponibile un aggiornamento dello stato sull'altra periferica. Il campo collegato indica il tipo di aggiornamento:
|
AudioStatusPoint
Campo del report sullo stato per il punto di controllo audio
| Opcode | Descrizione |
|---|---|
| 0 | Stato OK |
| -1 | Comando sconosciuto |
| -2 | Parametri non validi |
Annunci per il servizio GATT ASHA
L'UUID del servizio deve essere nel pacchetto dell'annuncio. Nell'annuncio o nel frame della risposta alla scansione, le periferiche devono avere Dati di servizio:
| Offset in byte | Nome | Descrizione |
|---|---|---|
| 0 | Durata dell'annuncio | >= 0x09 |
| 1 | Tipo di annuncio | 0x16 (Service Data - 16-bits UUID) |
| 2-3 | UUID servizio |
0xFDF0 (little-endian) Nota: si tratta di un ID temporaneo. |
| 4 | Versione del protocollo | 0x01 |
| 5 | Funzionalità |
|
| 6-9 | HiSyncID troncato | I quattro byte più significativi di HiSyncId. Questi byte dovrebbero essere la parte più casuale dell'ID. |
Le periferiche devono avere un tipo di dato Nome locale completo che indichi il nome dell'apparecchio acustico. Questo nome verrà utilizzato nell'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 i tipi di dati del nome e del servizio ASHA nello stesso tipo di frame (ADV o SCAN RESP), i due tipi di dati ("Nome locale completo" e "Dati di servizio per il servizio ASHA") devono essere visualizzati nello stesso frame. In questo modo, lo scanner del dispositivo mobile può acquisire entrambi i dati nello stesso risultato di scansione.
Durante l'accoppiamento iniziale, è importante che le periferiche annuncino a una velocità sufficientemente elevata da consentire al dispositivo mobile di rilevarle e accoppiarsi rapidamente.
Sincronizzare i dispositivi periferici sinistro e destro
Per poter utilizzare il Bluetooth sui dispositivi mobili Android, i dispositivi periferici devono essere sincronizzati. La riproduzione sui dispositivi periferici sinistro e destro deve essere sincronizzata in tempo. Entrambi i dispositivi periferici devono riprodurre contemporaneamente i sample audio dalla fonte.
I dispositivi periferici possono sincronizzare il proprio orario utilizzando un numero di sequenza premesso a ogni pacchetto del payload audio. La parte centrale garantisce che i pacchetti audio destinati a essere riprodotti contemporaneamente su ogni 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 ripetono dopo 256 pacchetti audio. Poiché la dimensione e la frequenza di campionamento di ogni pacchetto audio sono fisse per ogni connessione, le due periferiche possono dedurre il tempo di riproduzione relativo. Per ulteriori informazioni sul pacchetto audio, consulta Formato e sincronizzazione dei pacchetti audio.
La parte centrale aiuta fornendo attivatori ai dispositivi binaurali quando potrebbe essere necessaria la sincronizzazione. Questi attivatori informano ogni periferica dello stato del suo dispositivo periferico accoppiato ogni volta che viene eseguita un'operazione che potrebbe influire sulla sincronizzazione. I trigger sono:
-
Nell'ambito del comando
«Start»di AudioControlPoint, viene fornito lo stato di connessione corrente dell'altro lato dei dispositivi biauricolari. -
Ogni volta che viene eseguita 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 biauricolari.
Formato e temporizzazione dei pacchetti audio
L'imballaggio dei frame audio (blocchi di sample) in pacchetti consente allo strumento di elaborazione dell'ascolto di ricavare il timing dalle ancore di temporizzazione del livello link. Per semplificare l'implementazione:
- Un frame audio deve sempre corrispondere all'intervallo di connessione nel tempo. Ad esempio, se l'intervallo di connessione è 20 ms e la frequenza di campionamento è di 16 kHz, il frame audio deve contenere 320 campioni.
- Le frequenze di campionamento nel sistema sono limitate ai multipli di 8 kHz 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 precedere i frame audio. Il byte di sequenza deve essere conteggiato con a capo e consentire alla periferica di rilevare la mancata corrispondenza del buffer o il sottoflusso.
-
Un frame audio deve sempre rientrare in un unico pacchetto LE. Il frame audio deve essere inviato come pacchetto L2CAP separato. La dimensione della PDU LL
LE deve essere:
dimensione del payload audio + 1 (contatore di sequenza) + 6 (4 per l'intestazione L2CAP, 2 per l'SDU) - Un evento di connessione deve essere sempre sufficientemente grande da contenere 2 pacchetti audio e 2 pacchetti vuoti per un ACK per riservare la larghezza di banda per le ritrasmissioni. Tieni presente 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 offrire una certa flessibilità alla centrale, 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 degli ottetti di output G.722 fa riferimento alla 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 riportati di seguito. Questo è un elenco non esaustivo delle configurazioni che la centrale può implementare.
| Codec | Velocità in bit | Intervallo di connessione | Lunghezza cavo (1M/2M PHY) | Dimensioni del payload audio |
|---|---|---|---|---|
| G.722 a 16 kHz | 64 kbit/s | 20 ms | 5000/3750 us | 160 byte |
Avviare e interrompere uno stream audio
Prima di avviare uno stream audio, la parte centrale esegue query sulle periferiche e stabilisce un codec di denominatore comune. La configurazione dello stream procede quindi nella seguente sequenza:
- Vengono letti PSM e, facoltativamente, RenderDelay. Questi valori possono essere memorizzati nella cache dalla centrale.
- Il canale L2CAP CoC è aperto: la periferica deve concedere inizialmente 8 crediti.
- Viene emesso un aggiornamento della connessione per passare al collegamento ai parametri richiesti per il codec scelto. La centrale potrebbe eseguire questo aggiornamento della connessione prima della connessione CoC nel passaggio precedente.
- Sia l'host centrale che quello periferico aspettano l'evento di completamento dell'aggiornamento.
-
Riavvia l'encoder audio e reimposta il conteggio della sequenza dei pacchetti su 0.
Su AudioControlPoint viene emesso un comando
«Start»con i parametri pertinenti. Prima di avviare lo streaming, la centrale attende una notifica di stato positiva del comando«Start»precedente dalla periferica. Questa attesa dà alla periferica il tempo di preparare la pipeline di riproduzione audio. Durante lo streaming audio, la replica deve essere disponibile a ogni evento di connessione, anche se la latenza della replica corrente potrebbe non essere pari a zero. - La periferica prende il primo pacchetto audio dalla coda interna (numero di sequenza 0) e lo riproduce.
La centrale emette il comando "Stop" per chiudere lo stream audio. Dopo questo comando, la periferica non deve essere disponibile a ogni evento di connessione. Per riavviare lo streaming audio, segui la sequenza sopra riportata, iniziando dal passaggio 5. Quando la centrale non è in streaming audio, deve comunque mantenere una connessione LE per i servizi GATT.
La periferica non deve emettere un aggiornamento della connessione alla centrale. Per risparmiare energia, la centrale potrebbe inviare un aggiornamento di connessione alla periferica quando non è in streaming audio.