Audio Bluetooth Low Energy

Bluetooth Low Energy Audio (LEA) garantisce che gli utenti possano ricevere audio ad alta fedeltà senza sacrificare la durata della batteria e consente loro di passare senza problemi da un caso d'uso all'altro. Android 13 (livello API 33) include il supporto integrato per LEA.

La maggior parte delle cuffie LEA sarà in modalità duale finché la quota di mercato dei dispositivi sorgente LEA non aumenterà. Gli utenti devono essere in grado di accoppiare e configurare entrambi i trasporti sulle cuffie dual mode.

Casi d'uso

Potresti voler integrare LEA per i seguenti casi d'uso:

  • Condivisione dell'audio: gli utenti possono condividere contemporaneamente più stream audio con uno o più dispositivi di ricezione audio. L'audio viene sincronizzato tra il dispositivo di origine e i dispositivi connessi.

  • Trasmissione audio: gli utenti possono trasmettere l'audio ad amici e familiari, oltre a connettersi a trasmissioni pubbliche per informazioni, intrattenimento o accessibilità.

  • Supporto del codec audio LC3: questo è il codec audio predefinito e sostituisce il codec SBC utilizzato per A2DP (media) e mSBC in HFP (voce). LC3 è più efficiente, riconfigurabile e di qualità superiore.

  • Miglioramenti del campionamento audio: le cuffie possono mantenere un'elevata qualità dell'audio in uscita quando si utilizzano i microfoni. Bluetooth Classic riduce la qualità audio quando si utilizzano microfoni Bluetooth. Con BLE Audio, il campionamento di input e output può raggiungere i 32 kHz.

  • Microfono stereo: gli hearable possono registrare l'audio con microfoni stereo per miglioramenti dell'audio spaziale.

  • Supporto del profilo HAP (Hearing Aid Profile): HAP offre agli utenti una maggiore accessibilità e un utilizzo migliore rispetto ai protocolli ASHA precedenti. Gli utenti possono utilizzare i propri apparecchi acustici per le telefonate e le applicazioni VoIP.

  • Supporto del protocollo EATT (Enhanced Attribute Protocol): EATT ti consente di inviare più comandi contemporaneamente ai dispositivi hearable accoppiati.

Scenari chiave

Esistono quattro categorie principali di casi d'uso:

  1. Conversazionale: le applicazioni di composizione e VoIP che richiedono un routing di comunicazione a bassa latenza offrono un audio di alta qualità e un minore utilizzo della batteria.

  2. Gaming: il microfono simultaneo e la riproduzione ad alta fedeltà consentono ai giochi di riprodurre in streaming audio di alta qualità sugli hearable. Un'app di gioco può accedere all'input audio BLE quando un gioco attiva il microfono Bluetooth come pronto per l'uso. In questo modo, quando un giocatore avvia una conversazione dal vivo con un altro giocatore, l'app di gioco può utilizzare i dati del microfono senza ritardi.

  3. Contenuti multimediali: le applicazioni multimediali possono impostare il dispositivo preferito del gestore audio. L'utente può eseguire l'override di questa impostazione modificando il dispositivo preferito nelle impostazioni del sistema.

  4. Accessibilità: gli apparecchi acustici che supportano BLE Audio possono utilizzare il microfono, consentendo agli utenti di utilizzarli continuamente per una chiamata.

API e metodi BLE Audio

Le seguenti API e i seguenti metodi sono necessari per supportare i dispositivi audio BLE Audio:

AudioManager

  • setCommunicationDevice() seleziona il dispositivo audio da utilizzare per i casi d'uso di comunicazione, ad esempio chiamate vocali o videochiamate. Questo metodo può essere utilizzato dalle applicazioni di chat vocale o videochiamata per selezionare un dispositivo audio diverso da quello selezionato per impostazione predefinita dalla piattaforma. Questa API sostituisce le seguenti API ritirate: startBluetoothSco(), stopBluetoothSco() e setSpeakerphoneOn().
  • clearCommunicationDevice() viene chiamato dopo che l'app ha terminato una chiamata o una sessione per garantire all'utente un'esperienza ottimale quando passa da un'applicazione all'altra.

BluetoothProfile

  • BluetoothLeAudio controlla il servizio Bluetooth utilizzando un oggetto proxy.

Telecom InCallService

Telecom CallControl

Informazioni sul dispositivo audio

  • AudioDeviceInfo.TYPE_BLE_HEADSET descrive il tipo di dispositivo audio come un dispositivo LEA. Utilizzato per identificare se il dispositivo hearable è un dispositivo LEA.

Registratore audio

  • setPreferredDevice() imposta il dispositivo preferito da utilizzare per il routing audio. L'utente può eseguire l'override di questa impostazione nelle impostazioni di sistema.

Adattatore Bluetooth

  • isLeAudioSupported(): restituisce una costante @BluetoothStatusCodes (FEATURE_SUPPORTED, FEATURE_NOT_SUPPORTED o un codice di errore) che indica se l'hardware del dispositivo supporta LE Audio.
  • isLeAudioBroadcastSourceSupported(): restituisce una costante @BluetoothStatusCodes (FEATURE_SUPPORTED, FEATURE_NOT_SUPPORTED o un codice di errore) che indica se l'hardware del dispositivo supporta la sorgente di trasmissione LE Audio.

Guide basate sul caso d'uso

Di seguito sono riportate le linee guida per l'implementazione di LEA in base a casi d'uso specifici.

Applicazioni di comunicazione vocale

Le applicazioni di comunicazione vocale possono scegliere di gestire il routing audio e lo stato del dispositivo gestendo autonomamente il proprio stato o utilizzando l'API Telecom, che esegue il routing audio e la logica di stato per te.

Queste due soluzioni ti consentono di controllare il routing audio e di passare da un dispositivo Bluetooth all'altro. Per saperne di più, consulta la guida alle chiamate gestite da Telecom.

Applicazioni di registrazione audio

  • Media Recorder: quando registri l'audio utilizzando Media Recorder, puoi registrare in stereo se il dispositivo audio Bluetooth supporta LEA. Per saperne di più, consulta la guida alla registrazione audio.

Consigli per il visore

Con l'uscita di un numero sempre maggiore di cuffie LEA, abbiamo riscontrato problemi nei test reali che compromettono l'esperienza utente. La specifica non copre tutti questi problemi. La tabella seguente fornisce un elenco di consigli che i produttori di cuffie LEA devono seguire per migliorare l'esperienza end-to-end per gli utenti Android.

Descrizione Contesto
Supporto della Cross Transport Key Derivation (CTKD) per le cuffie dual-mode:
  • Supporta la derivazione della chiave sia per l'accoppiamento da Classic a LE sia per l'accoppiamento da LE a Classic.
 La maggior parte delle nuove cuffie LEA sarà dual-mode finché la quota di mercato dei dispositivi sorgente LEA non aumenterà. È importante che gli utenti possano accoppiare le cuffie dual-mode senza problemi e configurare entrambi i trasporti. Questo è importante anche per l'accoppiamento rapido di Google.

Supporta gli annunci mirati (TA) se vuoi che le tue cuffie LEA si riconnettano in modo affidabile ai dispositivi di origine.

Gli auricolari LE Audio devono utilizzare gli annunci di trasporto per richiedere una connessione in entrata dai dispositivi centrali.

Verrà aggiunto alla prossima versione di BT SIG.

 A differenza del modello di paging di BR/EDR, in cui una connessione può essere avviata sia dallo smartphone che dalle cuffie, una connessione in LEA deve essere avviata dal dispositivo centrale. Molte cuffie non utilizzano i TA, il che significa che il dispositivo centrale potrebbe non essere in grado di riconnettersi alla periferica senza aggiungerla a una lista consentita. Tuttavia, una soluzione alternativa con lista consentita potrebbe impedire alle cuffie di connettersi a un dispositivo centrale diverso. Pertanto, è importante che le cuffie LEA supportino correttamente i TA in modo che il dispositivo centrale possa riconnettersi in modo affidabile senza soluzioni alternative che potrebbero interrompere le connessioni multipunto.
Rilevabilità ottimizzata per gli auricolari dual mode
  • L'auricolare principale - componente BR/EDR deve trasmettere utilizzando il proprio indirizzo pubblico e attivare la ricerca e la scansione della pagina con il proprio nome disponibile tramite EIR, nonché impostare il bit 14 dell'audio LE su 1 nelle classi di servizio principali della classe di dispositivo (CoD).
  • Auricolare principale - Componente LE: l'auricolare principale deve eseguire un annuncio Connettibile e Rilevabile (Limitato o Generale) utilizzando lo stesso indirizzo pubblico del componente BR/EDR e lo stesso nome locale completo del componente BR/EDR, con la categoria di aspetto impostata su una categoria di aspetto appropriata che corrisponda al tipo di dispositivo remoto con l'aspettativa che il dispositivo centrale utilizzi queste informazioni per regolare le proprie UI e policy di routing audio.
  • Auricolare secondario - Solo LE: l'auricolare secondario deve eseguire un annuncio collegabile e non rilevabile con la categoria di aspetto impostata su una categoria di aspetto appropriata che corrisponda al tipo di dispositivo remoto, con l'aspettativa che il dispositivo centrale utilizzi queste informazioni per regolare le proprie UI e policy di routing audio

    Gli auricolari devono scegliere dinamicamente un leader dal gruppo CSIP come dispositivo principale. Se l'auricolare è dual-mode, il dispositivo principale deve essere dual-mode per garantire che le funzionalità LE e Classic funzionino correttamente dopo l'accoppiamento.

 In questo modo, gli auricolari LEA dual-mode non vengono visualizzati come voci duplicate nelle impostazioni Bluetooth, il che potrebbe confondere gli utenti e compromettere l'esperienza di accoppiamento LEA.

L'elezione dinamica del leader è particolarmente importante per i dispositivi dual-mode che vengono accoppiati in modo incrementale. Ad esempio, se durante l'accoppiamento iniziale è disponibile un solo auricolare, questo deve presentarsi come un dispositivo dual-mode. Quando un utente accoppia il secondo auricolare in un secondo momento, deve solo accoppiarlo con il componente LE e CSIP si assicurerà che vengano raggruppati su Android.

L'indirizzo di identità è consigliato durante l'accoppiamento perché il componente BR/EDR espone già l'indirizzo pubblico del dispositivo ai dispositivi nelle vicinanze.
Supportare l'Enhanced Attribute Protocol (EATT). Riduce la latenza di accoppiamento e connessione.
Supportare la memorizzazione nella cache GATT robusta. Riduce la latenza di connessione, in particolare per gli auricolari TWS.
Supporto della classificazione secondaria della connessione. Consente una pianificazione dei pacchetti più flessibile e un potenziale risparmio della batteria.
Assicurati che durante la pre-elaborazione e la post-elaborazione sia per la riproduzione che per l'acquisizione, la pipeline di elaborazione del segnale possa funzionare a 16, 24, 32 e 48 kHz, oltre a supportare frequenze più elevate. Sfrutta le frequenze di campionamento più elevate supportate per i percorsi di acquisizione delle chiamate LEA o VoIP e la riproduzione di contenuti multimediali.
Supporto di LE Power Control Gestione dell'alimentazione migliorata

Supporto del tipo di contesto

Descrizione Contesto
Utilizza tutti i tipi di contesto specificati in Assigned Numbers 6.12.3, a meno che le cuffie non supportino esplicitamente un determinato tipo di contesto. Ad esempio, se il tipo di contesto "Gioco" non è supportato, Android invierà i suoni del gioco. In particolare, tieni presente che il tipo di contesto "Non specificato" non significa "qualsiasi tipo di contesto" e non copre i tipi di contesto non supportati.

Quando il dispositivo centrale interagisce con l'ASCS del dispositivo periferico, la periferica deve connettersi all'MCS e al TBS del dispositivo centrale.

Il dispositivo centrale potrebbe non utilizzare sempre LE Audio come percorso di streaming, perché potrebbe tornare a utilizzare A2DP o HFP. Il dispositivo periferico può utilizzare l'interazione ASCS come indicazione per stabilire se il dispositivo centrale utilizzerà LE audio per lo streaming.

Alcuni esempi di interazioni ASCS sono la lettura, la scrittura e la registrazione per la notifica.

Consigli per i trasmettitori Auracast

Questa sezione fornisce consigli per la configurazione dei trasmettitori Auracast.

Trasmissioni intermittenti

Gli annunci audio negli spazi pubblici, come i terminal dei trasporti, sono spesso intermittenti e separati da lunghi periodi di silenzio. La trasmissione continua di silenzio o audio di sottofondo tra gli annunci consuma la batteria del ricevitore e impedisce agli utenti di ascoltare lo stream audio principale, come i contenuti multimediali locali o un altro stream Auracast attivo.

Per migliorare l'esperienza utente, Android consiglia ai trasmettitori Auracast di rispettare le seguenti linee guida per la gestione delle trasmissioni intermittenti.

Definizioni

  • Audio di interesse: i contenuti informativi principali destinati all'utente, come un annuncio di un gate o di un treno.
  • Audio di sottofondo: silenzio, rumore statico o musica d'ambiente di sottofondo trasmessi tra i periodi di audio di interesse.
  • Trasmissione intermittente: una trasmissione che alterna periodi di audio di interesse e periodi di audio di sottofondo o nessun audio.

Identificazione delle trasmissioni intermittenti

Per designare una trasmissione come trasmissione intermittente, l'emittente deve includere la struttura LTV (Length-Type-Value) dei metadati Audio_Active_State [1] in due posizioni:

  1. La struttura BASE dei metadati di livello 2 (annunci periodici) [2]
  2. The Public Broadcast Announcement Metadata (Extended Advertisements) [3]

Per aiutare il ricevitore a identificare la trasmissione intermittente e decidere se riprodurre lo stream, l'emittente deve anche impostare con precisione la struttura LTV dei metadati Streaming_Audio_Context [1].

Identificazione dell'audio di interesse

Per segnalare dinamicamente se una trasmissione intermittente contiene audio di interesse in un determinato momento, il trasmettitore utilizza le strutture LTV dei metadati Audio_Active_State.

  • Metadati di livello 2 della struttura BASE: un valore pari a 0x01 indica che i BIS in un sottogruppo contengono audio di interesse.
  • Metadati dell'annuncio di trasmissione pubblica: un valore pari a 0x01 indica che almeno uno dei BIS all'interno di un BIG contiene audio di interesse.

I valori LTV dei metadati Audio_Active_State devono essere impostati su 0x01 poco prima della trasmissione dell'audio di interesse, per consentire a un dispositivo di scansione di sincronizzarsi con una sorgente di trasmissione pubblica. Al contrario, deve essere impostato su 0x00 poco dopo la fine della trasmissione.

Sfruttare il contesto dell'audio in streaming

Fornire un contesto esplicito aiuta il framework Android e i dispositivi di ricezione a dare la priorità agli stream in entrata. Ad esempio, un sistema di diffusione sonora (PA) può impostare il tipo Streaming_Audio_Context su Instructional per consentire agli annunci di interrompere in modo pulito la riproduzione di contenuti multimediali locali di un ricevitore e riprenderla senza problemi in un secondo momento.

Riferimenti

[1] Bluetooth Assigned Numbers, https://www.bluetooth.com/specifications/assigned-numbers/
[2] Basic Audio Profile, https://www.bluetooth.com/specifications/specs/basic-audio-profile-1-0-3/
[3] Public Broadcast Profile, https://www.bluetooth.com/specifications/specs/public-broadcast-profile-1-0-2/