La funzionalità di routing combinato dei dispositivi audio aggiunge il supporto per lo streaming audio su più dispositivi audio contemporaneamente. Utilizzando questa funzionalità, le app privilegiate possono selezionare più dispositivi preferiti per una particolare strategia tramite API di sistema. Le app possono scoprire le funzionalità dei dispositivi audio in modo più preciso utilizzando le API pubbliche fornite da questa funzionalità. Per le versioni Android 11 e precedenti, l'implementazione del framework audio ha un supporto limitato per più dispositivi audio dello stesso tipo (ad esempio, 2 auricolari Bluetooth A2DP) collegati contemporaneamente. Inoltre, le regole di routing audio predefinite non consentono agli utenti di selezionare più dispositivi dello stesso tipo per un determinato caso d'uso.
A partire da Android 12, queste limitazioni vengono rimosse per consentire nuovi casi d'uso come la trasmissione audio, il multicasting su un gruppo di cuffie audio BLE o la selezione simultanea di più schede audio USB. Il routing su più dispositivi USB contemporaneamente non è supportato.
A partire da Android 14, il framework USB supporta il routing su più dispositivi USB a condizione che i dispositivi USB siano di diversi tipi di dispositivi audio ed è disponibile il supporto del kernel e del fornitore per connettere più dispositivi USB contemporaneamente.
Questa pagina spiega come implementare il supporto per lo streaming audio su più dispositivi audio e come convalidare l'implementazione di questa funzionalità.
Supporta lo streaming audio su più dispositivi audio
Esistono due set di API in Android 12 che supportano questa funzionalità:
- Le API di sistema gestiscono più dispositivi preferiti per una strategia.
- L'interfaccia HIDL, implementata dal fornitore come parte dell'HAL audio, riporta le funzionalità del dispositivo.
Le sezioni seguenti illustrano ciascuna di queste API in modo più dettagliato.
Gestisci più dispositivi preferiti per una strategia
Audio Policy Manager offre API di sistema per supportare meglio lo streaming audio su più dispositivi audio contemporaneamente. Queste API di sistema consentono di impostare, ottenere e rimuovere più dispositivi preferiti per una determinata strategia. Fino ad Android 12 questa funzionalità era supportata solo per un singolo dispositivo.
Audio Policy Manager introduce il concetto di dispositivi multimediali attivi per descrivere i dispositivi che con maggiore probabilità verranno selezionati per la riproduzione multimediale. Quando è collegato un dispositivo rimovibile, potrebbe essere necessario aprire i flussi di output HAL audio che possono essere instradati a questo dispositivo e verificare gli attributi supportati.
È necessario specificare un dispositivo audio quando si apre un flusso di output. Il dispositivo multimediale attivo è il dispositivo utilizzato quando i flussi di output vengono aperti in questo contesto.
La selezione del dispositivo multimediale attivo può cambiare a seconda dei dispositivi effettivamente collegati o disconnessi. Audio Policy Manager utilizza la seguente serie di regole per scegliere i dispositivi multimediali attivi:
- Se tutti i dispositivi preferiti per i media sono disponibili, vengono tutti scelti come dispositivi attivi.
- Altrimenti viene scelto l'ultimo dispositivo rimovibile connesso.
- Se non sono presenti dispositivi rimovibili collegati, per scegliere i dispositivi attivi vengono applicate le regole dei criteri audio predefiniti per la scelta dei dispositivi di output.
Un flusso di output deve soddisfare i seguenti criteri per essere riaperto e instradato ai dispositivi attivi in modo che venga scelta la migliore configurazione per la riproduzione:
- Il flusso di output deve supportare i dispositivi attivi.
- Il flusso di output deve supportare i profili dinamici.
- Il flusso di output non deve essere attualmente instradato verso dispositivi attivi.
Per applicare una nuova selezione del dispositivo, Audio Policy Manager chiude e riapre un flusso di output al momento della connessione del dispositivo se il flusso di output è inattivo o lo rinvia quando il flusso di output viene messo in standby.
Audio Policy Manager offre il seguente elenco di API di sistema (come definito in AudioManager.java
):
setPreferredDeviceForStrategy
Imposta il dispositivo preferito per l'instradamento audio per una determinata strategia. Tieni presente che il dispositivo potrebbe non essere disponibile nel momento in cui viene impostato il dispositivo preferito, ma verrà utilizzato una volta reso disponibile.
removePreferredDeviceForStrategy
Rimuove i dispositivi audio preferiti precedentemente impostati con
setPreferredDeviceForStrategy
osetPreferredDevicesForStrategy
.getPreferredDeviceForStrategy
Restituisce il dispositivo preferito per una strategia audio precedentemente impostata con
setPreferredDeviceForStrategy
osetPreferredDevicesForStrategy
.setPreferredDevicesForStrategy
Imposta i dispositivi preferiti per una determinata strategia.
getPreferredDevicesForStrategy
Restituisce i dispositivi preferiti per una strategia audio precedentemente impostata con
setPreferredDeviceForStrategy
osetPreferredDevicesForStrategy
.OnPreferredDevicesForStrategyChangedListener
Definisce un'interfaccia per la notifica delle modifiche nei dispositivi audio preferiti impostati per una determinata strategia audio.
addOnPreferredDevicesForStrategyChangedListener
Aggiunge un ascoltatore per ricevere notifiche sulle modifiche al dispositivo audio preferito dalla strategia.
removeOnPreferredDevicesForStrategyChangedListener
Rimuove un ascoltatore di modifiche aggiunto in precedenza al dispositivo audio preferito dalla strategia.
Segnala le funzionalità del dispositivo
Nell'ambito dell'implementazione dell'HAL audio, i fornitori implementano le API che supportano le funzionalità del dispositivo di reporting. Questa sezione spiega i tipi di dati e i metodi utilizzati per segnalare le funzionalità del dispositivo ed elenca alcune modifiche apportate all'audio HIDL HAL V7 per supportare più dispositivi.
Tipi di dati
Nell'audio HIDL HAL V7, le funzionalità del dispositivo vengono segnalate utilizzando le strutture AudioProfile
e AudioTransport
. La struttura AudioTransport
descrive la capacità di una porta audio con AudioProfile
per formati audio conosciuti o con descrittori hardware grezzi per formati non conosciuti dalla piattaforma. La struttura AudioProfile
contiene il formato audio, le frequenze di campionamento supportate dal profilo e l'elenco delle maschere di canale, come mostrato nel seguente blocco di codice da types.hal
:
/**
* Configurations supported for a certain audio format.
*/
struct AudioProfile {
AudioFormat format;
/** List of the sample rates (in Hz) supported by the profile. */
vec<uint32_t> sampleRates;
/** List of channel masks supported by the profile. */
vec<AudioChannelMask> channelMasks;
};
Nell'audio HIDL HAL V7, il tipo di dati AudioPort
è definito con le strutture AudioTransport
e AudioProfile
per descrivere le funzionalità del dispositivo.
Metodi HAL audio
Audio Policy Manager utilizza i seguenti metodi per interrogare le funzionalità del dispositivo:
-
getParameters:
un metodo generico per recuperare valori di parametri specifici del fornitore come i formati audio supportati e le rispettive frequenze di campionamento. -
getAudioPort:
restituisce l'elenco degli attributi supportati (come frequenze di campionamento, formati, maschere di canale, controller di guadagno) per una determinata porta audio.
Il seguente codice di IDevice.hal
mostra l'interfaccia per il metodo getAudioPort
:
/**
* Returns the list of supported attributes for a given audio port.
*
* As input, 'port' contains the information (type, role, address etc...)
* needed by the HAL to identify the port.
*
* As output, 'resultPort' contains possible attributes (sampling rates,
* formats, channel masks, gain controllers...) for this port.
*
* @param port port identifier.
* @return retval operation completion status.
* @return resultPort port descriptor with all parameters filled up.
*/
getAudioPort(AudioPort port)
generates (Result retval, AudioPort resultPort);
Modifiche all'API legacy
Per supportare più profili audio, la versione 3.2 dell'API legacy aggiunge una nuova struttura denominata audio_port_v7
. Vedi il codice sorgente per maggiori dettagli.
A causa dell'aggiunta di audio_port_v7
, la versione 3.2 dell'API legacy aggiunge una nuova API chiamata get_audio_port_v7
per interrogare le capacità dei dispositivi utilizzando la struttura audio_port_v7
.
Il seguente codice da audio.h
mostra la definizione dell'API get_audio_port_v7
:
/**
* Fills the list of supported attributes for a given audio port.
* As input, "port" contains the information (type, role, address etc...)
* needed by the HAL to identify the port.
* As output, "port" contains possible attributes (sampling rates,
* formats, channel masks, gain controllers...) for this port. The
* possible attributes are saved as audio profiles, which contains audio
* format and the supported sampling rates and channel masks.
*/
int (*get_audio_port_v7)(struct audio_hw_device *dev,
struct audio_port_v7 *port);
I dati dell'API legacy get_audio_port
devono essere inseriti nel nuovo formato AudioPort
quando la versione dell'API legacy è inferiore alla 3.2 e la versione HIDL HAL è 7 o successiva. In questo caso, si presuppone che tutte le frequenze di campionamento e le maschere di canale riportate da get_audio_port
siano supportate per tutti i formati restituiti, consentendo una mappatura diretta dai valori get_audio_port
alla nuova struttura AudioPort
.
Esempi di implementazioni API
Questa sezione descrive diverse suite di test contenenti metodi che utilizzano le API trattate nelle sezioni precedenti. Fare riferimento a questi metodi per alcuni esempi di come queste API vengono implementate e utilizzate.
Un esempio dell'utilizzo delle API di setPreferredDevicesForStrategy
, getPreferredDevicesForStrategy
, removePreferredDeviceForStrategy
e OnPreferredDevicesForStrategyChangedListener
si trova nel metodo PreferredDeviceRoutingTest
, che si trova in GTS.
Per vedere un esempio della nuova struttura in AudioDeviceInfo
in uso, vedere il metodo AudioManagerTest#testGetDevices
che si trova in CTS.
Un esempio dell'implementazione per get_audio_port_v7
si trova in audio_hal.c
e mostra come vengono interrogate le funzionalità per più dispositivi.
Validazione
Questa sezione fornisce informazioni sulla convalida CTS e GTS (Google Mobile Services Test Suite) di Audio Manager.
Prove CTS
I test CTS si trovano in android.media.cts.AudioManagerTest
.
Di seguito è riportato l'elenco dei test di Audio Manager disponibili:
AudioManagerTest#testGetDevices
Verifica le capacità precise del dispositivo audio. Verifica inoltre che i profili audio restituiti nella struttura
AudioDeviceInfo
conservino il contenuto del formato array appiattito precedente, ma siano nel nuovo formatoAudioProfile
.AudioManagerTest#testPreferredDevicesForStrategy
eAudioManagerTest#testPreferredDeviceForCapturePreset
Verificare che i dispositivi preferiti per la strategia e l'acquisizione dei test API correlati alle preimpostazioni vengano completati correttamente.
Prove GTS
I test GTS si trovano in com.google.android.gts.audioservice.AudioServiceHostTest
.
Per verificare se le API per i dispositivi preferiti per la strategia e la preimpostazione di acquisizione funzionano correttamente, esegui i test AudioServiceHostTest#testPreferredDeviceRouting
e AudioServiceHostTest#testPreferredDeviceRoutingForCapturePreset
.