Google si impegna a promuovere l'equità razziale per le comunità nere. Vedi come.
Questa pagina è stata tradotta dall'API Cloud Translation.
Switch to English

Apparecchi acustici Supporto audio tramite Bluetooth LE

Gli apparecchi acustici (HA) possono avere una migliore accessibilità sui 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 costante di audio, anche in presenza di perdita di pacchetti. Questo buffer fornisce qualità audio per i dispositivi acustici a spese della latenza.

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

Terminologia

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

Topologia di rete e architettura di sistema

Quando si utilizza CoC per gli apparecchi acustici, la topologia di rete assume una singola centrale e due periferiche, una sinistra e una destra, come mostrato nella Figura 1 . Il sistema audio Bluetooth visualizza le periferiche sinistra e destra come un singolo sink audio. Se manca una periferica, a causa di un adattamento 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 con entrambe le periferiche, la centrale considera il collegamento al dissipatore audio perso. In questi casi, la centrale indirizza l'audio verso un'altra uscita.


Figura 1. Topologia per l'associazione di apparecchi acustici a dispositivi mobili Android che utilizzano CoC su BLE

Quando la centrale non trasmette i dati audio alla periferica e può mantenere una connessione BLE, la centrale non dovrebbe disconnettersi dalla periferica. Il mantenimento della connessione consente la comunicazione dei dati con il server GATT che risiede sulla periferica.

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

  • Tieni traccia delle più recenti periferiche sinistra e destra accoppiate.
  • Supponiamo che le periferiche siano in uso se esiste un accoppiamento valido. La centrale tenta di connettersi o riconnettersi con il dispositivo accoppiato quando si perde la connessione.
  • Supponiamo 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 un set di apparecchi acustici con un determinato UUID e designatori sinistro / destro nel sistema operativo, non il processo di associazione 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 BT 4.2 o superiore conforme. LE Secure Connections è altamente raccomandato.
  • avere il supporto centrale almeno 2 collegamenti LE simultanei con parametri come descritto nel formato e nella tempistica del pacchetto audio .
  • avere il supporto periferico almeno 1 collegamento LE con i parametri descritti nel formato e nella tempistica del pacchetto audio .
  • disporre di un controllo del flusso basato sul credito LE [BT Vol 3, Part A, Sec 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 non zero maximum_CE_Length e minimum_CE_Length .
  • 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 payload in formato e tempistiche del pacchetto audio .
  • avere il set di periferiche i MaxRxOctets e MaxRxTime parametri nelle LL_LENGTH_REQ o LL_LENGTH_RSP fotogrammi per essere i più piccoli valori necessari che sono necessari per queste specifiche. Ciò consente alla centrale di ottimizzare il proprio programma orario durante il calcolo del tempo necessario per ricevere un frame.

Si consiglia vivamente che il supporto centrale e periferico 2 MB PHY, come specificato nella specifica BT 5.0. La centrale deve supportare collegamenti audio di almeno 64 kbit / s su 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 pubblicizzerà questo servizio quando è in modalità rilevabile generale per consentire alla centrale di riconoscere un sink audio. Qualsiasi operazione di streaming audio LE deve richiedere la crittografia. Lo streaming audio BLE è costituito dalle seguenti caratteristiche:

Caratteristica Proprietà Descrizione
ReadOnlyProperties Leggere Vedi ReadOnlyProperties .
AudioControlPoint Scrivi e scrivi senza risposta Punto di controllo per il flusso audio. Vedi AudioControlPoint .
AudioStatusPoint Lettura / 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 tra -128 e 0 che indica la quantità di attenuazione da applicare al segnale audio in streaming, che varia da -48 dB a 0 dB. L'impostazione -128 deve essere interpretata come completamente silenziata, ovvero il livello di volume non silenziato più basso è -127 che equivale all'attenuazione di -47,625 dB. All'impostazione 0, un tono sinusoidale rail-to-rail trasmesso deve rappresentare un equivalente di ingresso 100 dBSPL sull'apparecchio acustico. La centrale deve scorrere in scala reale nominale e utilizzare questa variabile per impostare il livello di presentazione desiderato nella periferica.
LE_PSM_OUT Leggere PSM da utilizzare per il collegamento del canale audio. Da scegliere dalla gamma dinamica [BT Vol 3, Part A, Sec 4.22]

Gli UUID assegnati al servizio e le 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 ASHA GATT, la periferica deve anche implementare il servizio di informazioni sui dispositivi per consentire alla centrale di rilevare i nomi dei produttori e i nomi dei dispositivi della periferica.

ReadOnlyProperties

ReadOnlyProperties ha i seguenti valori:

Byte Descrizione
0 Versione - deve essere 0x01
1 Vedi DeviceCapabilities .
2-9 Vedi 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 su zero.
15-16 ID codec supportati. Questa è una maschera di bit di ID codec supportati. Un 1 in una posizione di bit corrisponde a un codec supportato. Ad esempio, 0x0002 indica che è supportato G.722 a 16 kHz. Tutti gli altri bit devono essere impostati su 0.

DeviceCapabilities

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

HiSyncID

Questo campo deve essere unico 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 identificativi dell'azienda 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

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

ID codec

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

Numero ID / Bit Codec e frequenza di campionamento Bitrate richiesto Frame time Obbligatorio su centrale (C) o periferico (P)
0 Riservato Riservato Riservato Riservato
1 G.722 @ 16 kHz 64 kbit / s Variabile C e P
2-15 sono riservati.
0 è anche riservato.

AudioControlPoint

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

opcode 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 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 bit del tipo audio indica i tipi audio presenti nel flusso:
  • 0 - Sconosciuto
  • 1 - Suoneria
  • 2 - Chiamata telefonica
  • 3 - Media
Il campo othertate indica se l'altro lato dei dispositivi binaurali è collegato. Il valore del campo è 1 quando è collegato l'altro dispositivo periferico, altrimenti il ​​valore è 0.

La periferica non deve richiedere aggiornamenti della connessione prima che sia stato ricevuto un codice operativo «Stop» .
2 «Stop» Nessuna Indica alla periferica di interrompere il rendering dell'audio. Una nuova sequenza di impostazione audio deve essere avviata dopo questo arresto per rendere nuovamente l'audio.
3 «Status»
  • uint8_t connected
Informa la periferica connessa che è presente un aggiornamento di stato sull'altra periferica. Il campo collegato indica il tipo di aggiornamento:
  • 0 - Altre periferiche disconnesse
  • 1 - Altre periferiche collegate
  • 2 - Si è verificato un aggiornamento dei parametri di connessione LE su entrambe le connessioni

Pubblicità per il servizio ASHA GATT

L' UUID del servizio deve essere nel pacchetto di annunci. Nella pubblicità o nel frame di risposta alla scansione, le periferiche devono avere un Dati di servizio:

Byte offset Nome Descrizione
0 Lunghezza d.C. > = 0x09
1 Tipo di annuncio 0x16 (Dati di servizio - UUID a 16 bit)
2-3 UUID di servizio 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 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), i due tipi di dati ("Nome locale completo" e "Dati di servizio per il servizio ASHA") devono apparire nello stesso frame. Ciò consente allo scanner del dispositivo mobile di ottenere entrambi i dati nello stesso risultato di scansione.

Durante l'associazione iniziale, è importante che le periferiche pubblicizzino a una velocità sufficiente per consentire al dispositivo mobile di scoprire rapidamente le periferiche e collegarsi ad esse.

Sincronizzazione dei dispositivi periferici sinistro e destro

Per funzionare con Bluetooth su dispositivi mobili Android, i dispositivi periferici sono tenuti a 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 progressivo anteposto a ciascun pacchetto del payload audio. La centrale garantisce che i pacchetti audio che devono 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 ripetono dopo 256 pacchetti audio. Poiché ogni dimensione di pacchetto audio e frequenza di campionamento sono fissi per ogni connessione, le due periferiche possono dedurre il tempo di riproduzione relativo. Per ulteriori informazioni sul pacchetto audio, vedere Formato e tempistiche del pacchetto audio .

L'assistente centrale fornisce trigger ai dispositivi binaurali quando potrebbe essere necessario eseguire la sincronizzazione. Questi trigger informano ogni periferica dello stato del dispositivo periferico associato ogni volta che si verifica un'operazione che può 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'è una connessione, disconnessione o operazione di aggiornamento dei parametri di connessione su una periferica, il comando «Status» di AudioControlPoint viene inviato all'altro lato dei dispositivi binaurali.

Formato e tempistiche del pacchetto audio

Il confezionamento di frame audio (blocchi di campioni) in pacchetti consente allo strumento acustico di ricavare il timing dagli ancoraggi di timing dello strato di collegamento. Per 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 è di 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 antepone i frame audio. Il byte di sequenza deve essere conteggiato con avvolgimento e consentire alla periferica di rilevare la mancata corrispondenza o il underflow del buffer.
  • Un frame audio deve sempre adattarsi a un singolo pacchetto LE. Il frame audio deve essere inviato come pacchetto L2CAP separato. La dimensione della PDU LE LL deve essere:
    dimensione del payload audio + 1 (contatore sequenze) + 6 (4 per intestazione L2CAP, 2 per SDU)
  • Un evento di connessione dovrebbe essere sempre abbastanza grande da contenere 2 pacchetti audio e 2 pacchetti vuoti affinché un ACK riservi la larghezza di banda per le ritrasmissioni. Si noti che il pacchetto audio può 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ò cambiare 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) Dimensione del payload audio
G.722 @ 16 kHz 64 kbit / s 20 ms 5000/3750 noi 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. La configurazione 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 - la periferica inizialmente concede 8 crediti.
  3. Viene emesso un aggiornamento della connessione per commutare il collegamento ai parametri richiesti per il codec selezionato. 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 completo di aggiornamento.
  5. Riavviare il codificatore audio e reimpostare il conteggio della sequenza di pacchetti su 0. Su AudioControlPoint viene emesso un comando «Start» con i parametri pertinenti. La centrale attende una notifica di stato riuscita del precedente comando «Start» dalla periferica prima dello streaming. Questa attesa dà il tempo periferico per preparare la sua pipeline di riproduzione audio. Durante lo streaming audio, la replica dovrebbe essere disponibile in 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 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, passare attraverso la sequenza sopra, a partire dal passaggio 5. Quando la centrale non esegue lo streaming audio, dovrebbe 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 emettere un aggiornamento della connessione alla periferica quando non è in streaming audio.