Routing combinato di dispositivi audio

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:

  1. Se tutti i dispositivi preferiti per i media sono disponibili, vengono tutti scelti come dispositivi attivi.
  2. Altrimenti viene scelto l'ultimo dispositivo rimovibile connesso.
  3. 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 o setPreferredDevicesForStrategy .

  • getPreferredDeviceForStrategy

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

  • setPreferredDevicesForStrategy

    Imposta i dispositivi preferiti per una determinata strategia.

  • getPreferredDevicesForStrategy

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

  • 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 formato AudioProfile .

  • AudioManagerTest#testPreferredDevicesForStrategy e AudioManagerTest#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 .