La funzionalità di routing combinato dei dispositivi audio aggiunge il supporto per lo streaming audio a più dispositivi audio contemporaneamente. Utilizzando questa funzionalità, le app con privilegi possono selezionare più dispositivi preferiti per una determinata strategia tramite le 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 Android 11 e versioni precedenti, l'implementazione del framework audio ha un supporto limitato per più dispositivi audio dello stesso tipo (ad esempio, 2 cuffie Bluetooth A2DP) connessi contemporaneamente. Le regole di routing audio predefinite non consentono inoltre agli utenti di selezionare più dispositivi dello stesso tipo per un caso d'uso specifico.
A partire da Android 12, queste limitazioni vengono rimosse per consentire nuovi casi d'uso come la trasmissione audio, il multicast a un gruppo di cuffie audio BLE o la selezione simultanea di diverse schede audio USB. Il routing a più dispositivi USB contemporaneamente non è supportato.
A partire da Android 14, il framework USB supporta il routing a più dispositivi USB, a condizione che i dispositivi USB siano di diversi tipi di dispositivi audio e che il kernel e il fornitore supportino la connessione di più dispositivi USB contemporaneamente.
Questa pagina spiega come implementare il supporto dello streaming audio su più dispositivi audio e come convalidare l'implementazione di questa funzionalità.
Supporto dello streaming audio su più dispositivi audio
In Android 12 sono disponibili due set di API 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, segnala le funzionalità del dispositivo.
Le sezioni seguenti descrivono in dettaglio ciascuna di queste API.
Gestire 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 hanno maggiori probabilità di essere scelti per la riproduzione di contenuti multimediali. Quando è collegato un dispositivo rimovibile, gli stream di output HAL audio che possono essere indirizzati a questo dispositivo potrebbero dover essere aperti e analizzati per gli attributi supportati.
Quando si apre uno stream di output, è necessario specificare un dispositivo audio. Il dispositivo multimediale attivo è quello utilizzato quando i flussi di output vengono aperti in questo contesto.
La selezione del dispositivo multimediale attivo può variare a seconda dei dispositivi effettivamente connessi o disconnessi. Audio Policy Manager utilizza la seguente serie di regole per scegliere i dispositivi multimediali attivi:
- Se tutti i dispositivi preferiti per i contenuti multimediali sono disponibili, vengono scelti come dispositivi attivi.
- In caso contrario, viene scelto l'ultimo dispositivo rimovibile connesso.
- Se non sono collegati dispositivi rimovibili, vengono applicate le regole della policy audio predefinite per la scelta dei dispositivi di output per scegliere i dispositivi attivi.
Un flusso di output deve soddisfare i seguenti criteri per essere riaperto e indirizzato ai dispositivi attivi in modo che venga selezionata la migliore configurazione per la riproduzione:
- Il flusso di output deve supportare i dispositivi attivi.
- Lo stream di output deve supportare i profili dinamici.
- Lo stream di output non deve essere attualmente indirizzato a 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 oppure rimanda l'operazione a 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 il routing audio per una determinata strategia. Tieni presente che il dispositivo potrebbe non essere disponibile al momento dell'impostazione del dispositivo preferito, ma viene utilizzato una volta reso disponibile.
removePreferredDeviceForStrategy
Rimuove i dispositivi audio preferiti impostati in precedenza con
setPreferredDeviceForStrategy
osetPreferredDevicesForStrategy
.getPreferredDeviceForStrategy
Restituisce il dispositivo preferito per una strategia audio impostata in precedenza con
setPreferredDeviceForStrategy
osetPreferredDevicesForStrategy
.setPreferredDevicesForStrategy
Imposta i dispositivi preferiti per una determinata strategia.
getPreferredDevicesForStrategy
Restituisce i dispositivi preferiti per una strategia audio impostata in precedenza con
setPreferredDeviceForStrategy
osetPreferredDevicesForStrategy
.OnPreferredDevicesForStrategyChangedListener
Definisce un'interfaccia per la notifica delle modifiche ai dispositivi audio preferiti impostati per una determinata strategia audio.
addOnPreferredDevicesForStrategyChangedListener
Aggiunge un listener per ricevere notifiche sulle modifiche al dispositivo audio preferito dalla strategia.
removeOnPreferredDevicesForStrategyChangedListener
Rimuove un listener aggiunto in precedenza per le modifiche al dispositivo audio preferito dalla strategia.
Includi le funzionalità del dispositivo nei report
Nell'ambito dell'implementazione di Audio HAL, i fornitori implementano le API che supportano la segnalazione delle funzionalità del dispositivo. Questa sezione spiega i tipi di dati e i metodi utilizzati per segnalare le funzionalità del dispositivo ed elenca alcune modifiche apportate a HIDL HAL audio V7 per supportare più dispositivi.
Tipi di dati
In 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 i formati audio noti o con
descrittori hardware non elaborati per i formati non noti alla piattaforma. La struttura
AudioProfile
contiene il formato audio, le frequenze di campionamento supportate
dal profilo e l'elenco delle maschere dei canali, come mostrato nel seguente blocco di codice
di 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;
};
In audio HIDL HAL V7, il tipo di dati AudioPort
è definito con le strutture
AudioTransport
eAudioProfile
per descrivere le funzionalità del dispositivo.
Metodi HAL audio
Audio Policy Manager utilizza i seguenti metodi per eseguire query sulle funzionalità del dispositivo:
getParameters:
Un metodo generico per recuperare i valori dei parametri specifici del fornitore, ad esempio i formati audio supportati e le rispettive frequenze di campionamento.getAudioPort:
Restituisce l'elenco degli attributi supportati (come frequenze di campionamento, formati, maschere dei canali, controlli del 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, AudioPo
rt resultPort);
Modifiche all'API precedente
Per supportare più profili audio, la versione 3.2 dell'API legacy aggiunge una nuova
struttura chiamata audio_port_v7
. Per ulteriori dettagli, consulta il codice sorgente.
A causa dell'aggiunta di audio_port_v7
, la versione 3.2 dell'API precedente aggiunge una
nuova API chiamata get_audio_port_v7
per eseguire query sulle funzionalità dei dispositivi utilizzando la
struttura audio_port_v7
.
Il seguente codice di 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 au
dio_port_v7 *port);
I dati della vecchia API get_audio_port
devono essere inseriti nel nuovo formato AudioPort
quando la versione dell'API precedente è inferiore alla 3.2 e la versione HIDL HAL è 7 o successive. In questo caso, si presume che tutte le frequenze di campionamento e le maschere
dei canali segnalate da get_audio_port
siano supportate per tutti i formati
restituiti, consentendo una mappatura semplice dai valori di 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. Consulta questi metodi per alcuni esempi di come vengono implementate e utilizzate queste API.
Un esempio di utilizzo delle API di sistema setPreferredDevicesForStrategy
,
getPreferredDevicesForStrategy
, removePreferredDeviceForStrategy
e
OnPreferredDevicesForStrategyChangedListener
è nel metodo
PreferredDeviceRoutingTest
, che si trova in GTS.
Per vedere un esempio della nuova struttura in AudioDeviceInfo
in uso, consulta il metodo AudioManagerTest#testGetDevices
, che si trova in CTS.
Un esempio di implementazione per get_audio_port_v7
si trova in
audio_hal.c
e mostra come vengono eseguite query sulle funzionalità per più dispositivi.
Convalida
Questa sezione fornisce informazioni sulla convalida CTS e GTS (Google Mobile Services Test Suite) di Audio Manager.
Test 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 funzionalità precise del dispositivo audio. Verifica inoltre che i profili audio restituiti nella struttura
AudioDeviceInfo
conservino i contenuti del formato array precedente e compresso, ma siano nel nuovo formatoAudioProfile
.AudioManagerTest#testPreferredDevicesForStrategy
eAudioManagerTest#testPreferredDeviceForCapturePreset
Verifica che i test API correlati ai preset di strategia e acquisizione dei dispositivi preferiti vengano completati correttamente.
Test 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 l'acquisizione preimpostata
funzionano correttamente, esegui i test AudioServiceHostTest#testPreferredDeviceRouting
e AudioServiceHostTest#testPreferredDeviceRoutingForCapturePreset
.