Configura i criteri relativi all'audio

La release Android 10 include un significativo refactoring dell'audio Policy Manager per fornire maggiore flessibilità per supportare casi d'uso complessi del settore auto e motori:

  • Strategie di routing specifiche per OEM.
  • Gruppi di volumi personalizzabili per gruppi di tipi di flussi di dati precedenti utilizzando le stesse curve di volume.
  • Strategie di routing dichiarate dal motore dei criteri audio anziché essere hardcoded.
  • Curve e gruppi di volume gestiti dal motore dei criteri audio.
  • Refactoring interno preparazione a una futura suddivisione tra codice comune e codice configurabile e offre una gestione dei dispositivi audio più ricca. Ad esempio, l'uso di tutte le proprietà dei dispositivi non solo il proprio tipo nelle regole dei criteri.

Android 7.0 ha introdotto un formato file di configurazione dei criteri audio (XML) per che descrive la topologia audio.

Release di Android precedenti richieste utilizzando device/<company>/<device>/audio/audio_policy.conf per dichiarare i dispositivi audio presenti sul prodotto (puoi vedere un esempio di questo file per l'hardware audio del Galaxy Nexus device/samsung/tuna/audio/audio_policy.conf). Tuttavia, CONF è un un formato semplice e proprietario troppo limitato per descrivere topologie complesse verticali come televisori e automobili.

Android 7.0 ha deprecato audio_policy.conf e aggiunto supporto per la definizione di una topologia audio utilizzando un formato file XML leggibile da una persona, dispone di una vasta gamma di strumenti di editing e analisi ed è flessibile in modo da descrivere topologie audio complesse. Android 7.0 utilizza Flag di build USE_XML_AUDIO_POLICY_CONF per scegliere il file XML dei file di configurazione.

Vantaggi del formato XML

Come nel file CONF, il file XML consente di definire il numero e i tipi di profili stream di output e di input, dispositivi utilizzabili per la riproduzione e l'acquisizione attributi audio. Inoltre, il formato XML offre i seguenti miglioramenti:

  • In Android 10, vengono gestite più app di registrazione consentiti contemporaneamente.
    • L'avvio della registrazione non viene mai rifiutato a causa di una situazione di contemporaneità.
    • registerAudioRecordingCallback(AudioManager.AudioRecordingCallback cb) il callback avvisa i clienti delle modifiche al percorso di acquisizione.
  • Nelle seguenti situazioni, un cliente riceve campioni audio silenziosi:
    • È attivo un caso d'uso sensibile alla privacy (ad esempio VOICE_COMMUNICATION).
    • Il client non dispone di un servizio in primo piano o di una UI in primo piano.
    • I ruoli speciali sono riconosciuti dalle norme:
      • Servizio di accessibilità: è possibile registrare anche se è attivo un caso d'uso sensibile alla privacy.
      • Assistente: i dati sono considerati sensibili alla privacy se l'UI si trova in alto.
  • I profili audio hanno una struttura simile ai descrittori audio semplici HDMI, consentendo un insieme di frequenze di campionamento/maschere del canale per ogni formato audio.
  • Esistono definizioni esplicite di tutte le possibili connessioni tra dispositivi e stream. In precedenza, una regola implicita consentiva di collegare tutti i dispositivi collegati allo stesso HAL del modulo, impedendo al criterio audio di controllare le connessioni richieste con una patch audio su quelle di livello inferiore. Nel formato XML, la descrizione della topologia definisce i limiti della connessione.
  • Il supporto di include evita la ripetizione di invii standard A2DP, USB o di reindirizzamento. le tue definizioni.
  • Le curve di volume sono personalizzabili. In precedenza, le tabelle dei volumi erano impostate come hardcoded. Nel file XML le tabelle del volume sono descritte e possono essere personalizzate.

Il modello all'indirizzo frameworks/av/services/audiopolicy/config/audio_policy_configuration.xml mostra molte di queste funzionalità in uso.

Formato file e posizione

Il nuovo file di configurazione dei criteri audio è audio_policy_configuration.xml e si trova in /system/etc. I seguenti esempi mostrano una semplice configurazione dei criteri audio nel Formato file XML per Android 12 e per le versioni seguenti Android 12.

La struttura di primo livello contiene moduli che corrispondono a ciascun HAL audio modulo hardware, in cui ogni modulo include un elenco di porte combinate, porte dei dispositivi route:

  • Le porte mix descrivono i possibili profili di configurazione per i flussi che può essere aperta nell'HAL audio per la riproduzione e l'acquisizione.
  • Le porte dei dispositivi descrivono i dispositivi che è possibile collegare il tipo (e facoltativamente indirizzo e proprietà audio, se pertinenti).
  • Route è separato dal descrittore di porta combinato, attivazione della descrizione dei percorsi da un dispositivo all'altro o da stream a dispositivo.

Le tabelle di volume sono semplici elenchi di punti che definiscono la curva utilizzata per tradurre da un indice di UI a un volume in dB. Un file di inclusione separato fornisce i valori predefiniti ma ogni curva per un determinato caso d'uso e categoria di dispositivi può essere sovrascritto.

Inclusioni di file

È possibile utilizzare il metodo XML Inclusions (XInclude) per includere le norme relative all'audio di configurazione disponibili in altri file XML. Tutti i file inclusi devono seguono la struttura descritta sopra con le seguenti restrizioni:

  • I file possono contenere solo elementi di primo livello.
  • I file non possono contenere elementi XInclude.

Utilizza le funzionalità incluse per evitare di copiare l'Android Open Source Project (AOSP) standard informazioni sulle configurazioni dei moduli HAL audio a tutte le configurazioni dei criteri audio (che è soggetto a errori). Un file XML di configurazione dei criteri audio standard è disponibile per i seguenti HAL audio:

  • A2DP: a2dp_audio_policy_configuration.xml
  • Modifica il routing del submix: rsubmix_audio_policy_configuration.xml
  • USB: usb_audio_policy_configuration.xml

Organizzazione del codice dei criteri audio

AudioPolicyManager.cpp è suddiviso in più moduli per semplificarne la manutenzione e la configurazione. L'organizzazione di frameworks/av/services/audiopolicy include i campi seguenti moduli.

Modulo Descrizione
/managerdefault Include le interfacce generiche e l'implementazione del comportamento comune a tutti app. Simile a AudioPolicyManager.cpp con motore funzionalità e concetti comuni astratti.
/common Definisce le classi base (ad esempio, le strutture dei dati per lo stream audio di input e output) profili, descrittori dei dispositivi audio, patch audio e porte audio). In precedenza definiti all'interno di AudioPolicyManager.cpp.
/engine

Implementa le regole che definiscono il dispositivo e i volumi da utilizzare caso d'uso specifico. Implementa un'interfaccia standard con la parte generica, come trovare il dispositivo appropriato per un determinato caso d'uso di riproduzione o acquisizione, oppure Impostare i dispositivi connessi o lo stato esterno (ovvero uno stato di chiamata di utilizzo forzato) che possono alterare la decisione di routing.

Disponibile in due versioni: configurable e default. Per informazioni su come selezionare la versione, vedi Configurazione tramite framework dei parametri.
/engineconfigurable Implementazione del motore dei criteri che si basa sul framework dei parametri (vedi di seguito). La configurazione si basa sul framework dei parametri e su dove viene impostato il criterio definiti da file XML.
/enginedefault Implementazione del motore delle norme basata sulla precedente Gestione norme audio di Android implementazioni. Questa è l'impostazione predefinita e include regole hardcoded che corrispondono alle implementazioni Nexus e AOSP.
/service Include interfacce di binder, threading e blocco dell’implementazione con l'interfaccia al resto del framework.

Configurazione mediante framework dei parametri

Il codice delle norme relative all'audio è organizzato in modo da semplificare la comprensione e mantenere supportando al contempo un criterio audio definito interamente dalla configurazione . La progettazione dei criteri audio e dell'organizzazione si basa sul parametro Intel Framework, basato su plug-in e regole, per la gestione dei parametri.

L'utilizzo dei criteri audio configurabili consente agli OEM dei fornitori di:

  • Descrivere la struttura di un sistema e i suoi parametri in XML.
  • Scrivere (in C++) o riutilizzare un backend (plug-in) per accedere alle descrizioni parametri.
  • Definire (in XML o in una lingua specifica del dominio) condizioni/regole su cui un determinato parametro deve avere un determinato valore.

AOSP include un esempio di file di configurazione dei criteri audio che utilizza il parametro Framework all'indirizzo Frameworks/av/services/audiopolicy/engineconfigurable/parameter-framework/example/Settings/PolicyConfigurableDomains.xml. Per dettagli, consulta la documentazione Intel sul Framework dei parametri.

In Android 10 o versioni precedenti, il criterio audio configurabile viene selezionato utilizzando l'opzione di build USE_CONFIGURABLE_AUDIO_POLICY. In Android 11 o versioni successive, la versione dei criteri relativi all'audio motore selezionato nel file audio_policy_configuration.xml. Per selezionare il motore dei criteri audio configurabile, imposta il valore dell'attributo engine_library attributo dell'elemento globalConfiguration a configurable come nell'esempio seguente:

<audioPolicyConfiguration>
    <globalConfiguration engine_library="configurable" />
...
</audioPolicyConfiguration>

API di routing dei criteri audio

Android 6.0 ha introdotto un'API pubblica Enumeration and Selection basata su al top dell'infrastruttura di patch audio/porta audio e consente agli sviluppatori di indicare una preferenza per un input o output di dispositivo specifico tracce o record audio collegati.

In Android 7.0, l'API Enumeration and Selection viene verificata tramite i test CTS ed è stato esteso per includere il routing per gli stream audio nativi C/C++ (OpenSL ES). Il routing dei flussi nativi continua a essere eseguito in Java, con l'aggiunta un'interfaccia AudioRouting che sostituisce, combina e ritira i metodi espliciti di routing specifici per AudioTrack e AudioRecord corsi.

Per maggiori dettagli sull'API Enumeration and Selection, consulta Android interfacce di configurazione specifiche e OpenSLES_AndroidConfiguration.h. Per maggiori dettagli sul routing audio, consulta AudioRouting.

Supporto multicanale

Se il tuo hardware e driver supportano l'audio multicanale tramite HDMI, puoi inviare lo stream audio direttamente all'hardware audio (questa operazione bypassa il mixer AudioFlinger in modo che non venga sottoposto a downmix a due canali.) L'HAL audio deve indicare se un profilo di stream di output supporta l'audio multicanale le funzionalità di machine learning. Se l'HAL espone le proprie funzionalità, lo strumento di gestione dei criteri predefinito consente la riproduzione multicanale tramite HDMI. Per i dettagli di implementazione, consulta device/samsung/tuna/audio/audio_hw.c.

Per specificare che il prodotto contiene un'uscita audio multicanale, modifica il di configurazione dei criteri audio per descrivere l'output multicanale prodotto. Il seguente esempio frameworks/av/services/audiopolicy/config/primary_audio_policy_configuration_tv.xml Mostra una maschera del canale dinamica, il che significa che la Gestione norme relative agli audio esegue una query sul canale. maschere supportate dal sink HDMI dopo la connessione.

Puoi anche specificare una maschera statica del canale, AUDIO_CHANNEL_OUT_5POINT1. Il mixer di AudioFlinger esegue il downmix automaticamente i contenuti in stereo quando vengono inviati a un dispositivo audio che non supportare l'audio multicanale.

Codec multimediali

Assicurati che i codec audio supportati da hardware e driver siano corretti per il tuo prodotto. Per maggiori dettagli, vedi Esposizione dei codec ai Framework.