Routing combinato dei dispositivi audio

La funzionalità di inoltro dei dispositivi audio combinati aggiunge il supporto per lo streaming audio su più dispositivi audio contemporaneamente. Tramite questa funzionalità, le app con privilegi possono selezionare più dispositivi preferiti per una determinata strategia tramite le API di sistema. Le app possono scoprire più precisamente le funzionalità dei dispositivi audio utilizzando le API pubbliche fornite da questa funzionalità. Per le versioni di Android 11 e 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. 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 multicast a un gruppo di cuffie audio BLE o la selezione di più schede audio USB contemporaneamente. Il routing a più dispositivi USB contemporaneamente non è supportato.

A partire da Android 14, il framework USB supporta il routing su più dispositivi USB, a condizione che si tratti di tipi di dispositivi audio diversi e che sia disponibile il supporto del kernel e del fornitore per collegare 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à.

Supportare lo streaming audio su più dispositivi audio

In Android 12 sono presenti due insiemi di API che supportano questa funzionalità:

  • Le API di sistema gestiscono più dispositivi preferiti per una strategia.
  • L'interfaccia HIDL, implementata dal fornitore nell'ambito 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, recuperare 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 dei contenuti multimediali. Quando è collegato un dispositivo rimovibile, gli stream di output HAL audio che possono essere instradati a questo dispositivo potrebbero dover essere aperti e sottoposti a sonda per verificare gli attributi supportati.

È necessario specificare un dispositivo audio quando si apre uno stream di output. Il dispositivo multimediale attivo è il dispositivo utilizzato quando gli stream di output vengono aperti in questo contesto.

La selezione dei dispositivi multimediali attivi può variare a seconda dei dispositivi effettivamente collegati o scollegati. Audio Policy Manager utilizza la seguente serie di regole per scegliere i dispositivi multimediali attivi:

  1. Se sono disponibili tutti i dispositivi preferiti per i contenuti multimediali, vengono scelti tutti come dispositivi attivi.
  2. In caso contrario, viene scelto l'ultimo dispositivo rimovibile connesso.
  3. Se non sono collegati dispositivi rimovibili, le regole dei criteri audio predefiniti per la scelta dei dispositivi di output vengono applicate per scegliere i dispositivi attivi.

Uno stream di output deve soddisfare i seguenti criteri per essere riaperto e inoltrato ai dispositivi attivi in modo da scegliere la configurazione migliore per la riproduzione:

  • Lo stream di output deve supportare i dispositivi attivi.
  • Lo stream di output deve supportare i profili dinamici.
  • Lo stream di output non deve essere attualmente instradato ai dispositivi attivi.

Per applicare una nuova selezione del dispositivo, Audio Policy Manager chiude e riapre uno stream di output alla connessione del dispositivo se lo stream di output è inattivo o lo rimanda al momento in cui lo stream 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 verrà utilizzato non appena sarà reso disponibile.

  • removePreferredDeviceForStrategy

    Rimuove i dispositivi audio preferiti impostati in precedenza consetPreferredDeviceForStrategy o setPreferredDevicesForStrategy.

  • getPreferredDeviceForStrategy

    Restituisce il dispositivo preferito per una strategia audio impostata in precedenza con setPreferredDeviceForStrategy o setPreferredDevicesForStrategy.

  • setPreferredDevicesForStrategy

    Imposta i dispositivi preferiti per una determinata strategia.

  • getPreferredDevicesForStrategy

    Restituisce i dispositivi preferiti per una strategia audio impostata in precedenza con setPreferredDeviceForStrategy o setPreferredDevicesForStrategy.

  • OnPreferredDevicesForStrategyChangedListener

    Definisce un'interfaccia per la notifica delle modifiche ai dispositivi audio preferiti impostati per una determinata strategia audio.

  • addOnPreferredDevicesForStrategyChangedListener

    Aggiunge un ascoltatore per ricevere notifiche delle modifiche al dispositivo audio preferito dalla strategia.

  • removeOnPreferredDevicesForStrategyChangedListener

    Rimuove un ascoltatore delle modifiche apportate al dispositivo audio preferito dalla strategia, aggiunto in precedenza.

Segnala le funzionalità del dispositivo

Nell'ambito dell'implementazione dell'HAL audio, 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 e elenca alcune modifiche apportate in audio HIDL HAL V7 per supportare più dispositivi.

Tipi di dati

Nella versione 7 dell'HAL audio HIDL, le funzionalità del dispositivo vengono registrate 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 di canale, 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;
};

Nella versione 7 dell'audio HIDL HAL, 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 eseguire query sulle funzionalità del dispositivo:

  • getParameters:Un metodo generico per recuperare i valori dei parametri specifici del fornitore, come i formati audio supportati e le rispettive frequenze di campionamento.
  • getAudioPort:Restituisce l'elenco degli attributi supportati (ad es. frequenze di campionamento, formati, maschere di canale, controller di guadagno) per una determinata porta audio.

Il seguente codice di IDevice.hal mostra l'interfaccia del 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 precedente

Per supportare più profili audio, la versione 3.2 dell'API precedente aggiunge una nuova struttura denominata 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 audio_port_v7 *port);

I dati dell'API get_audio_port precedente devono essere inseriti nel nuovo formatoAudioPort quando la versione dell'API precedente è precedente alla 3.2 e la versione HIDL HAL è 7 o successiva. In questo caso, si presume 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 dei valori get_audio_port alla nuova struttura AudioPort.

Esempi di implementazioni dell'API

Questa sezione descrive diverse suite di test contenenti metodi che utilizzano le API descritte nelle sezioni precedenti. Consulta questi metodi per alcuni esempi di come queste API vengono implementate e utilizzate.

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 di Audio Manager tramite CTS e GTS (Google Mobile Services Test Suite).

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 dell'array appiattito precedente, ma siano nel nuovo formato AudioProfile.

  • AudioManagerTest#testPreferredDevicesForStrategy e AudioManagerTest#testPreferredDeviceForCapturePreset

    Verifica che i dispositivi preferiti per la strategia e la cattura delle impostazioni predefinite correlata ai test dell'API 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 per l'acquisizione dei preset funzionano correttamente, esegui i test AudioServiceHostTest#testPreferredDeviceRouting e AudioServiceHostTest#testPreferredDeviceRoutingForCapturePreset.