Gli apparecchi acustici (HA) possono avere una migliore accessibilità su Dispositivi mobili basati su Android tramite L2CAP orientato alla connessione (CoC) tramite Bluetooth Low Energy (BLE). Il CdC utilizza un elastico buffer di diversi pacchetti audio per mantenere un flusso audio costante, in presenza di perdita di pacchetti. Questo buffer fornisce qualità audio per apparecchi acustici a scapito della latenza.
La progettazione del CdC fa riferimento Bluetooth Versione 5 della specifica di base (BT). Per rimanere allineati con le specifiche principali, tutti i pod i valori su questa pagina devono essere letti come Litt-endian.
Terminologia
- Central: il dispositivo Android che cerca annunci pubblicitari via Bluetooth.
- Periferica: l'apparecchio acustico che invia di pacchetti pubblicitari tramite Bluetooth.
Topologia di rete e architettura di sistema
Quando si utilizza CoC per gli apparecchi acustici, la topologia di rete presuppone che venga utilizzata una singola centrale e due periferiche, una sinistra e una destra, come si vede Figura 1. Il sistema audio Bluetooth guarda a sinistra e le periferiche giuste come un singolo sink audio. Se una periferica è non a causa di un adattamento monofonico o di una perdita di connessione, centrale mixa i canali audio destro e sinistro e trasmette l'audio alla periferica rimanente. Se la centrale perde la connessione periferiche, la centrale considera il link al sink audio hanno perso. In questi casi, la centrale instrada l'audio a un'altra uscita.
Figura 1. Topologia per l'accoppiamento di apparecchi acustici con
Dispositivi mobili Android che utilizzano CoC tramite BLE
Quando la centrale non trasmette dati audio in streaming alla periferica e può una connessione BLE, la centrale non deve disconnettersi periferica. Mantenimento della connessione consente alla comunicazione dei dati al server GATT presente sulla periferica.
Durante l'accoppiamento e la connessione di protesi uditive, la centrale deve:
- Tieni traccia delle periferiche destra e sinistra più recenti accoppiate.
- Supponi che le periferiche siano in uso se esiste un accoppiamento valido. La la centrale tenta di connettersi o riconnettersi dispositivo quando si perde la connessione.
- Se un accoppiamento viene eliminato, supponiamo che le periferiche non siano più in uso.
Nei casi precedenti, per accoppiamento si intende l'azione registrare un set di apparecchi acustici con un determinato UUID e indicatori sinistro/destro nel sistema operativo, non il processo di accoppiamento Bluetooth.
Requisiti di sistema
Per implementare correttamente CoC per una buona esperienza utente, il Bluetooth nei dispositivi centrali e periferici devono:
- implementare un controller conforme BT 4.2 o superiore. LE Secure Connections è vivamente consigliato.
- disporre di un supporto centrale per almeno 2 collegamenti LE simultanei con parametri descritto in Pacchetto audio formato e tempistiche.
- la periferica deve supportare almeno un link LE con i parametri descritto in Pacchetto audio formato e tempistiche.
- hanno un controllo del flusso basato sul credito LE [BT Vol 3, Part A, Sec 10.1]. I dispositivi devono supportare MTU e MPS di almeno 167 byte CoC ed essere in grado di memorizzare nel buffer fino a 8 pacchetti.
- dispongono di un’estensione della lunghezza dei dati LE [BT Vol 6, Part B, Sec 5.1.9] con con un payload di almeno 167 byte.
-
fare in modo che il dispositivo centrale supporti il comando di aggiornamento della connessione HCI LE
e rispettino le
maximum_CE_Lengthe le Parametriminimum_CE_Length. - la centrale mantiene la velocità effettiva dei dati per due connessioni LE CoC a due diverse periferiche con intervalli di connessione e payload nel pacchetto audio formato e tempistiche.
-
in cui la periferica sia impostata su
MaxRxOctetsParametriMaxRxTimeinLL_LENGTH_REQoLL_LENGTH_RSPframe per essere i valori obbligatori più piccoli necessari per queste specifiche. Questo consente alla centrale ottimizzare il proprio time scheduler per calcolare la quantità di tempo necessario per ricevere un frame.
È vivamente consigliato che la centrale e la periferica supportino 2 MB di PHY specificato nella specifica BT 5.0. La centrale deve supportare i link audio almeno 64 kbit/s su PHY 1M e 2M. Non utilizzare il PHY a lungo raggio BLE.
Il CdC utilizza i meccanismi Bluetooth standard per la crittografia a livello di link e salto di frequenza.
Servizi GATT ASHA
Una periferica deve implementare lo streaming audio per gli apparecchi acustici (ASHA) Servizio server GATT descritto di seguito. La periferica deve pubblicizzare questo servizio in modalità di rilevamento generale per consentire centrale riconoscerà un sink audio. Qualsiasi operazione di streaming LE audio richiede la crittografia. Lo streaming BLE audio è costituito le seguenti caratteristiche:
| Caratteristica | Proprietà | Descrizione |
|---|---|---|
| ProprietàSolaLettura | Letti | Vedi ReadOnlyProperties. |
| Punto di controllo audio | Scrittura e scrittura senza risposta | Punto di controllo per lo stream audio. Consulta AudioControlPoint. |
| Punto di stato audio | Lettura/notifica | Campo del report di stato per il punto di controllo audio. Consulta AudioStatusPoint. |
| Volume | Scrivi senza risposta | Byte compreso tra -128 e 0 che indica la quantità di attenuazione da applicare il segnale audio in streaming, compreso tra -48 dB e 0 dB. Impostazione -128 deve essere interpretato come l'audio completamente disattivato, ovvero il volume più basso senza audio di attenuazione è -127, che equivale a -47,625 dB di attenuazione. Impostando il valore 0, un tono sinusoidale rail-to-rail trasmesso in streaming deve rappresentare un input di 100 dBSPL equivalente sull'apparecchio acustico. La centrale avrà un flusso nominale scala e utilizzare questa variabile per impostare il livello di presentazione desiderato la periferica. |
| LE_PSM_OUT | Letti | PSM da utilizzare per il collegamento del canale audio. Da scegliere tra gamma dinamica [BT Vol 3, Part A, Sec 4.22] |
Gli UUID assegnati al servizio e alle caratteristiche:
UUID del servizio: {0xFDF0}
| Caratteristica | UUID |
|---|---|
| ProprietàSolaLettura | {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 deve anche implementare il Device Information Service per consentire alla centrale di rilevare i nomi dei produttori e i nomi dei dispositivi della periferica.
ProprietàSolaLettura
ReadOnlyProperties ha i seguenti valori:
| Byte | Descrizione |
|---|---|
| 0 | Versione: deve essere 0x01 |
| 1 | Vedi DeviceCapabilities. |
| 2-9 | Vedi HiSyncId. |
| 10 | Vedi FeatureMap. |
| 11-12 | Ritardo di rendering. Si tratta del tempo, in millisecondi, trascorso da quando riceve un frame audio fino al rendering della periferica l'output. Questi byte possono essere usati per ritardare un video si sincronizzano con l'audio. |
| 13-14 | Riservato per un uso futuro. Inizializza a zeri. |
| 15-16 | ID codec supportati. Questa è una maschera di bit di ID codec supportati. A 1 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. |
Funzionalità dispositivo
| Punta | Descrizione |
|---|---|
| 0 | Lato dispositivo (0: sinistra, 1: destra) |
| 1 | Indica se il dispositivo è autonomo e riceve dati in formato mono o se il Il dispositivo fa parte di un insieme (0: monofonico, 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 il lo stesso per il gruppo destro e sinistro.
| Byte | Descrizione |
|---|---|
| 0-1 | ID del produttore. È la Società Identificatori assegnati da BTSIG. |
| 2-7 | ID univoco che identifica il set di apparecchi acustici. È necessario impostare questo ID alla stessa periferica sinistra e destra. |
Mappa caratteristiche
| Punta | Descrizione |
|---|---|
| 0 | Streaming in 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 bit | Codec e frequenza di campionamento | Velocità in bit richiesta | Durata frame | Obbligatorio in zona centrale (C) o periferica (P) |
|---|---|---|---|---|
| 0 | Riservata | Riservata | Riservata | Riservata |
| 1 | G.722 a 16 kHz | 64 kbit/s | Variabile | C e P |
|
Ne sono riservate 2-15. È riservato anche 0. |
||||
Punto di controllo audio
Questo punto di controllo non può essere utilizzato quando il CoC LE è chiuso. Consulta Avvio e interrompendo uno stream audio per la descrizione della procedura.
| Codice operativo | Argomenti | Procedura secondaria GATT | Descrizione |
|---|---|---|---|
1 «Start» |
|
Scrivi con risposta e attendi un'ulteriore notifica di stato tramite caratteristica AudioStatusPoint. |
Indica alla periferica di reimpostare il codec e avviare
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 16k Hz. Il campo di bit del tipo di audio indica i tipi di audio presenti. nello stream:
La periferica non deve richiedere aggiornamenti della connessione prima di un È stata ricevuta l'operazione «Stop».
|
2 «Stop» |
Nessuno | Scrivi con risposta e attendi un'ulteriore notifica di stato tramite caratteristica AudioStatusPoint. | Indica alla periferica di interrompere il rendering dell'audio. Un nuovo audio la sequenza di configurazione deve essere avviata dopo questa interruzione nell'ordine indicato per eseguire nuovamente il rendering dell'audio. |
3 «Status» |
|
Scrivi senza risposta |
Informa la periferica connessa che è presente un aggiornamento di stato nella
un'altra periferica. Il campo connesso indica il tipo di aggiornamento:
|
Punto di stato audio
Campo del report di stato per il punto di controllo audio
| Codici operativi | Descrizione |
|---|---|
| 0 | Stato OK |
| -1 | Comando sconosciuto |
| -2 | Parametri non ammessi |
Pubblicità del servizio ASHA GATT
L'UUID del servizio deve trovarsi nel un pacchetto di pubblicità. Nella pubblicità o nella scansione di risposta, le periferiche devono includere i Dati di servizio:
| Offset byte | Nome | Descrizione |
|---|---|---|
| 0 | Lunghezza ANNUNCIO | >= 0 x 09 |
| 1 | Tipo di annuncio | 0x16 (Dati di servizio - UUID a 16 bit) |
| 2-3 | UUID del servizio |
0xFDF0 (little-endian) Nota: questo è un ID temporaneo. |
| 4 | Versione protocollo | 0x01 |
| 5 | Capacità |
|
| 6-9 | HiSyncID troncato | I quattro byte più significativi HiSyncId: Questi byte dovrebbero rappresentare la parte più casuale dell'ID. |
Le periferiche devono avere un nome locale completo tipo di dati che indica il nome dell'apparecchio acustico. Questo nome essere utilizzati nell'interfaccia utente del dispositivo mobile, in modo che l'utente possa selezionare il dispositivo giusto. Il nome non deve indicare la freccia sinistra o destra canale poiché queste informazioni sono fornite DeviceCapabilities.
Se le periferiche inseriscono il nome e i tipi di dati del servizio ASHA nello stesso tipo di frame (ADV o SCAN RESP), quindi i due tipi di dati ("Nome locale completo" e "Dati di servizio per il servizio ASHA") verranno visualizzati all'interno dello stesso frame. In questo modo lo scanner del dispositivo mobile può recuperare nello stesso risultato della scansione.
Durante l'accoppiamento iniziale, è importante che le periferiche fare pubblicità a una velocità tale da consentire rapidamente al dispositivo mobile a scoprire le periferiche e ad associarle.
Sincronizza i dispositivi periferici destro e sinistro
Per utilizzare il Bluetooth sui dispositivi mobili Android, sui dispositivi periferici devono garantire che siano sincronizzati. La riproduzione sui dispositivi periferici destro e sinistro deve essere sincronizzato nel tempo. Entrambe le periferiche devono riprodurre i campioni audio dal contemporaneamente.
I dispositivi periferici possono sincronizzare il proprio orario utilizzando una sequenza numero anteposto a ogni pacchetto del payload audio. Il fulcro garantisce che i pacchetti audio destinati a essere riprodotti con su ciascuna periferica hanno lo stesso numero di sequenza. La sequenza di incrementi di uno dopo ogni pacchetto audio. Ogni sequenza è lungo 8 bit, quindi i numeri di sequenza si ripeteranno dopo 256 e pacchetti audio. Poiché la dimensione e la frequenza di campionamento di ogni pacchetto audio sono fisse per ogni connessione, le due periferiche possono ricavare il relativo l'ora di riproduzione. Per ulteriori informazioni sul pacchetto audio, consulta Formato del pacchetto audio e dell'audiodescrizione.
La centrale aiuta fornendo trigger ai dispositivi binaurali durante la potrebbe essere necessario. Questi attivatori informano ogni periferica dello stato del dispositivo periferico accoppiato ogni volta che si verifica un'operazione potrebbero influire sulla sincronizzazione. Gli attivatori sono:
-
Nell'ambito del comando
«Start»di AudioControlPoint, l'attuale stato di connessione dell'altro lato della rete binaurale vengono forniti i dispositivi. -
In caso di connessione, disconnessione
un'operazione di aggiornamento
dei parametri di connessione su una periferica
il comando
«Status»di AudioControlPoint viene inviato a dall'altro lato dei dispositivi binaurali.
Formato e tempi del pacchetto audio
L'inserimento di fotogrammi audio (blocchi di campioni) in pacchetti consente all'udito strumentali ricavando la sincronizzazione dagli ancoraggi dei tempi dello strato di link. A semplificare l'implementazione:
- Un frame audio deve sempre corrispondere all'intervallo di connessione nel tempo. Ad esempio, se l'intervallo di connessione è di 20 ms e la frequenza di campionamento è 16 kHz, il frame audio dovrà contenere 320 campioni.
- Le frequenze di campionamento nel sistema sono limitate a multipli di 8 kHz hanno sempre un numero intero di campioni in un frame, indipendentemente la durata frame o l'intervallo di connessione.
- I frame audio devono essere anteposti da un byte sequenza. Il byte della sequenza deve contare sul wrap-around e consente alla periferica di rilevare una mancata corrispondenza o un underflow del buffer.
-
Un frame audio deve sempre rientrare in un singolo pacchetto LE. L'audio
deve essere inviato come pacchetto L2CAP separato. Le dimensioni della LE
La PDU LL sarà:
dimensione payload audio + 1 (contatore di sequenze) + 6 (4 per l'intestazione L2CAP, 2 per SDU) - Un evento di connessione deve sempre essere abbastanza grande da contenere due audio e 2 pacchetti vuoti affinché un ACK riservi la larghezza di banda le ritrasmissioni. Tieni presente che il pacchetto audio può essere frammentato al controller Bluetooth centrale. La periferica deve poter 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 è specificato. La lunghezza del pacchetto G.722 può cambiare in base alla connessione intervallo definito dalla centrale.
Il formato ottetto 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 supportano i seguenti parametri di connessione. Questo è un elenco non esaustivo di configurazioni che la centrale può implementare.
| Codec | Velocità in bit | Intervallo di connessione | Lunghezza CE (1/2 M PHY) | Dimensioni payload audio |
|---|---|---|---|---|
| G.722 a 16 kHz | 64 kbit/s | 20 ms | 5000/3750 noi | 160 byte |
Avviare e interrompere uno stream audio
Prima di avviare uno stream audio, la centrale esegue una query sulle periferiche e stabilisce un codec per denominatore comune. Stream quindi prosegue con la seguente sequenza:
- PSM e, facoltativamente, RenderDelay viene letto. Questi valori può essere memorizzato nella cache dalla centrale.
- Il canale L2CAP del CoC è aperto: la periferica concede 8 crediti all'inizio.
- Viene inviato un aggiornamento della connessione per cambiare il link ai parametri richiesto per il codec scelto. La centrale potrebbe eseguire questo aggiornamento della connessione prima della connessione CoC nel passaggio precedente.
- Sia l'host centrale sia l'host della periferica attendono l'aggiornamento completo dell'evento.
-
Riavvia il codificatore audio e reimposta il conteggio delle sequenze di pacchetti su 0.
Un comando
«Start»con i parametri pertinenti è emessa sull'AudioControlPoint. Il centralino attende una notifica dello stato corretta del comando«Start»precedente dalla periferica prima del flusso di dati. Questa attesa restituisce alla periferica per preparare la pipeline di riproduzione audio. Durante lo streaming audio, la replica dovrebbe essere disponibile a ogni evento di connessione anche se l'attuale una latenza di replica diversa da zero. - La periferica prende il primo pacchetto audio dalla sua coda interna (numero di sequenza 0) e la riproduce.
La centrale emette il comando «Stop» per chiudere stream audio. Dopo questo comando, non è necessario che la periferica sia disponibile di connessione. Per riavviare lo streaming audio, segui la sequenza precedente, iniziando dal passaggio 5. Quando la centralità non è audio in streaming, dovrebbe comunque mantenere una connessione LE per GATT i servizi di machine learning.
La periferica non deve inviare un aggiornamento della connessione alla centrale. Per risparmiare energia, la centrale potrebbe eseguire un aggiornamento della connessione periferica quando non riproduce audio in streaming.