Audio per auto e motori

Android Automotive OS (AAOS) si basa sullo stack audio Android principale per supportare i casi d'uso per l'uso come sistema di infotainment di un veicolo. AAOS è responsabile dei suoni di infotainment (ovvero contenuti multimediali, navigazione comunicazioni) ma non è direttamente responsabile dei cicalini e degli avvisi che hanno di disponibilità e tempistiche rigide. Sebbene AAOS fornisca indicatori e meccanismi per aiutare il veicolo a gestire l'audio, alla fine spetta al veicolo a decidere quali suoni devono essere riprodotti per il conducente e passeggeri, verificando che i suoni critici per la sicurezza e quelli normativi siano adeguatamente udibili senza interruzioni.

Poiché Android gestisce l'esperienza multimediale del veicolo, le fonti multimediali esterne come il sintonizzatore radio, deve essere rappresentato da app, in grado di gestire l'audio gli eventi chiave e i principali eventi multimediali per la fonte.

Android 11 include le seguenti modifiche all'audio relativo alle auto e motori assistenza:

• Selezione automatica della zona audio in base all'ID utente associato
• Nuovi utilizzi dell'impianto per supportare i suoni specifici delle autovetture
• Supporto per la messa a fuoco audio HAL
• Attenzione audio ritardata per gli stream non temporanei
• Impostazione utente per controllare l'interazione tra navigazione e chiamate

Audio e stream Android

I sistemi audio per automobili gestiscono i seguenti suoni e stream:

Figura 1. Diagramma dell'architettura basata sui flussi

Android gestisce i suoni provenienti dalle app per Android, controllando queste app e indirizzare i suoni ai dispositivi di uscita dell'HAL in base al tipo suono:

• Stream logici, noti come sorgenti nell'audio principale sono contrassegnate da attributi audio.
• Stream fisici, noti come dispositivi nell'audio principale non avere informazioni di contesto dopo la combinazione.

Per l'affidabilità, suoni esterni (provenienti da suoni come i cicalini di avviso delle cinture di sicurezza) sono gestite al di fuori di Android, sotto le HAL o anche in hardware separato. Gli implementer del sistema devono fornire un mixer accetta uno o più stream di input audio da Android e poi li combina trasmettere in streaming in modo adeguato con le sorgenti sonore esterne richieste dalla veicolo.

L'implementazione dell'HAL e il mixer esterno hanno la responsabilità di garantire che vengono uditi suoni esterni critici per la sicurezza e per il missaggio nel trasmettendoli in streaming e indirizzandoli ad altoparlanti adatti.

Suoni Android

Le app possono avere uno o più player che interagiscono tramite la piattaforma Android standard API (ad esempio AudioManager per il controllo dello stato attivo o MediaPlayer per lo streaming) per emettere uno o più flussi logici di dati audio. Questi dati può essere un formato mono a canale singolo o surround 7.1, ma viene instradato e trattato un'unica fonte. Lo stream di app è associato ad AudioAttributes che forniscono al sistema suggerimenti su come esprimere l'audio.

I flussi logici vengono inviati tramite AudioService e indirizzati a uno (e uno solo dei flussi di output fisici disponibili, ognuno dei quali è l'output di un mixer in AudioFlinger. Dopo aver mixato gli attributi audio a uno stream fisico, non sono più disponibili.

Ogni stream fisico viene quindi inviato all'HAL audio per il rendering e l'hardware. Nelle app automobilistiche, l'hardware di rendering può essere costituito da codec locali (simile ai dispositivi mobili) o un processore remoto nella parte fisica del veicolo in ogni rete. In ogni caso, è compito dell'implementazione di Audio HAL fornire dati di esempio effettivi e diventino udibili.

Stream esterni

Stream audio che non devono essere indirizzati tramite Android (per la certificazione o motivi di tempo) può essere inviata direttamente al mixer esterno. A partire da Android 11, L'HAL è ora in grado di richiedere lo stato attivo per questi suoni esterni per informare Android in modo che possa adottare le misure appropriate, come mettere in pausa i contenuti multimediali o impedire ad altri di concentrarsi.

Se gli stream esterni sono sorgenti multimediali che devono interagire con l'audio nell'ambiente in corso da Android (ad esempio, interrompi la riproduzione di MP3 quando il sintonizzatore esterno sia attivato), questi stream esterni devono essere rappresentati da un App per Android. Un'app di questo tipo richiederebbe il focus audio per conto della fonte multimediale anziché all'HAL e risponderanno alle notifiche mirate avvia/interrompe l'origine esterna in base alle esigenze per rientrare nell'attenzione di Android . L'app è anche responsabile della gestione degli eventi chiave multimediali, play/pausa. Un meccanismo suggerito per controllare questi dispositivi esterni è HwAudioSource.

Dispositivi di output

A livello di Audio HAL, il tipo di dispositivo AUDIO_DEVICE_OUT_BUS fornisce un dispositivo di output generico da utilizzare nei sistemi audio dei veicoli. L'autobus supporta porte indirizzabili (ogni porta è il punto di arrivo fisico) ed è previsto che sia l'unico tipo di dispositivo di output supportato in di un veicolo.

Un'implementazione di sistema può usare una porta bus per tutti i suoni Android, in Android mescola tutto in un unico stream. In alternativa, l'HAL può fornire una porta bus per ogni CarAudioContext per consentire simultanea di qualsiasi tipo di suono. Ciò permette all'HAL implementazione per mixare e attenuare i diversi suoni a seconda delle tue preferenze.

L'assegnazione dei contesti audio ai dispositivi di uscita avviene tramite: car_audio_configuration.xml.

Ingresso microfono

Durante l'acquisizione dell'audio, l'HAL audio riceve un openInputStream che include un argomento AudioSource che indica come l'input del microfono dovrebbe essere elaborato.

Origine VOICE_RECOGNITION (nello specifico l'Assistente Google) si aspetta uno stream con microfono stereo con un effetto di cancellazione eco (se disponibile), ma non viene applicata alcuna altra elaborazione. Il Beamforming dovrebbe essere eseguito dall'assistente.

Ingresso microfono multicanale

Per acquisire l'audio da un dispositivo con più di due canali (stereo), utilizza una della maschera dell'indice del canale invece della maschera dell'indice posizionale (ad esempio CHANNEL_IN_LEFT). Esempio:

final AudioFormat audioFormat = new AudioFormat.Builder()
    .setEncoding(AudioFormat.ENCODING_PCM_16BIT)
    .setSampleRate(44100)
    .setChannelIndexMask(0xf /* 4 channels, 0..3 */)
    .build();
final AudioRecord audioRecord = new AudioRecord.Builder()
    .setAudioFormat(audioFormat)
    .build();
audioRecord.setPreferredDevice(someAudioDeviceInfo);

Quando sia setChannelMask sia setChannelIndexMask sono impostati, AudioRecord utilizza solo il valore impostato da setChannelMask (massimo due canali).

Acquisizione simultanea

A partire da Android 10, il framework Android supporta l'acquisizione simultanea di input, ma con restrizioni per proteggere la privacy dell'utente. Nell'ambito di queste restrizioni, le origini virtuali come AUDIO_SOURCE_FM_TUNER vengono ignorate e come tali possono essere acquisiti contemporaneamente insieme a un normale ingresso (come il microfono). Inoltre, i contenuti HwAudioSources non sono considerati parte integrante di limitazioni di acquisizione.

App progettate per funzionare con AUDIO_DEVICE_IN_BUS dispositivi o con i dispositivi AUDIO_DEVICE_IN_FM_TUNER secondari devono fare affidamento identificare questi dispositivi e utilizzare AudioRecord.setPreferredDevice() per bypassare la logica di selezione dell'origine predefinita di Android.

Utilizzi audio

AAOS utilizza principalmente AudioAttributes.AttributeUsages per routing, regolazioni del volume e gestione dello stato attivo. Gli utilizzi sono rappresentazione del "perché" lo stream viene riprodotto. Di conseguenza, tutti gli stream e le richieste di messa a fuoco audio devono specificare un utilizzo per la riproduzione audio. Quando non è impostato in modo specifico durante la creazione di un oggetto AudioAttributes, l'utilizzo sarà il valore predefinito è USAGE_UNKNOWN. Anche se al momento viene trattato allo stesso modo come USAGE_MEDIA, questo comportamento non deve essere utilizzato per i contenuti multimediali per riprodurre un video.

Utilizzi da parte del sistema

In Android 11 sono stati introdotti gli utilizzi del sistema. Questi utilizzi si comportano in modo simile agli utilizzi stabiliti in precedenza, ad eccezione del fatto che richiedono API di sistema da utilizzare in combinazione con android.permission.MODIFY_AUDIO_ROUTING. Il nuovo di utilizzo del sistema sono:

• USAGE_EMERGENCY
• USAGE_SAFETY
• USAGE_VEHICLE_STATUS
• USAGE_ANNOUNCEMENT

Per creare un AudioAttributes con un utilizzo del sistema, usa AudioAttributes.Builder#setSystemUsage anziché setUsage. Chiamata a questo metodo con un utilizzo non di sistema comporterà il lancio di IllegalArgumentException. Inoltre, se sia l'uso che l'utilizzo del sistema sono stati impostati su un builder, verrà generato un IllegalArgumentException durante la creazione.

Per controllare quale utilizzo è associato a AudioAttributes , chiama AudioAttributes#getSystemUsage. Restituisce l'utilizzo o l'utilizzo del sistema associato.

Contesto audio

Per semplificare la configurazione dell'audio AAOS, gli utilizzi simili sono stati raggruppati in CarAudioContext. Questi contesti audio vengono utilizzati CarAudioService per definire routing, gruppi di volume e focus audio gestione dei dispositivi.

I contesti audio in Android 11 sono:

Mappatura tra contesti e utilizzi audio. Le righe evidenziate si riferiscono a nuovi utilizzi del sistema.

Audio multizona

Con il settore automobilistico arriva una nuova serie di casi d'uso per gli utenti simultanei che interagiscono con la piattaforma e cercano di usufruire di contenuti multimediali separati. Per esempio, un conducente può ascoltare musica in cabina mentre i passeggeri seduti sul sedile posteriore. stanno guardando un video di YouTube sul display posteriore. L'audio multizona consente consentendo la riproduzione simultanea di diverse sorgenti audio in aree diverse del veicolo.

L'audio multizona a partire da Android 10 consente agli OEM di configurare l'audio in zone separate. Ogni zona è un insieme di dispositivi all'interno del veicolo con i propri gruppi di volumi, la configurazione del routing per i contesti gestione dei dispositivi. In questo modo, la cabina principale potrebbe essere configurata come un unico audio mentre i jack per cuffie del display posteriore sono configurati come seconda zona.

Le zone sono definite come parte di car_audio_configuration.xml. CarAudioService legge quindi la configurazione e aiuta AudioService indirizzare gli stream audio in base alla zona associata. Ogni zona definisce per il routing in base ai contesti e all'uid dell'applicazione. Quando un giocatore creato, CarAudioService determina per quale zona si trova e quindi in base all'utilizzo, a quale dispositivo l'AudioFlinger deve indirizzare l'audio.

Inoltre, la messa a fuoco viene mantenuta in modo indipendente per ogni zona audio. Ciò consente in diverse zone per produrre audio in modo indipendente senza che interferiscono tra loro mantenendo le applicazioni che rispettano le modifiche attivo all'interno della propria zona. CarZonesAudioFocus entro CarAudioService è responsabile della gestione dell'attenzione zona di destinazione.

Figura 2. Configura audio multizona

HAL audio

Le implementazioni audio nel settore auto e motori si basano sullo standard Android Audio HAL, che include:

• IDevice.hal. Crea flussi di input e output, gestisce il volume principale e la disattivazione dell'audio, oltre a utilizzare:
  • createAudioPatch. Per creare patch esterne-esterne tra i dispositivi.
  • IDevice.setAudioPortConfig() per fornire volume per ogni stream fisico.
• IStream.hal. Insieme alle varianti di input e output, gestisce lo streaming di campioni audio da e verso l'hardware.

Tipi di dispositivi per auto e motori

I seguenti tipi di dispositivi sono pertinenti per le piattaforme automobilistiche.

Configurazione dei dispositivi audio

I dispositivi audio visibili ad Android devono essere definiti in /audio_policy_configuration.xml, che include i seguenti componenti:

• il nome del modulo. Supporta il tipo "principale" (per casi d'uso nel settore auto e motori), "A2DP", "remote_submix" e "USB". Il nome del modulo e l'audio corrispondente driver deve essere compilato in audio.primary.$(variant).so.
• devicePorts. Contiene un elenco di descrittori dei dispositivi per tutti i valori di input e output (inclusi quelli collegati in modo permanente e i dispositivi rimovibili) che possono essere da questo modulo.
• Per ogni dispositivo di output è possibile definire un controllo del guadagno, che consiste in valori min/max/default/step in millibel (1 millibel = 1/100 dB = 1/1000 bel).
• L'attributo indirizzo su un'istanza devicePort può essere utilizzato per trovare dispositivo mobile, anche se sono presenti più dispositivi con lo stesso tipo di dispositivo AUDIO_DEVICE_OUT_BUS.
• mixPort. Contiene un elenco di tutti gli stream di output e di input esposti dal audio HAL. Ogni istanza mixPort può essere considerata come un flusso fisico Android AudioService.
• route. Definisce un elenco di possibili connessioni tra input e output tra dispositivi o tra stream e dispositivo.

L'esempio seguente definisce un dispositivo di output bus0_phone_out in cui tutte le Gli stream audio Android vengono mixati tramite mixer_bus0_phone_out. Il percorso segue stream di output di mixer_bus0_phone_out al dispositivo bus0_phone_out.

<audioPolicyConfiguration version="1.0" xmlns:xi="http://www.w3.org/2001/XInclude">
    <modules>
        <module name="primary" halVersion="3.0">
            <attachedDevices>
                <item>bus0_phone_out</item>
<defaultOutputDevice>bus0_phone_out</defaultOutputDevice>
            <mixPorts>
                <mixPort name="mixport_bus0_phone_out"
                         role="source"
                         flags="AUDIO_OUTPUT_FLAG_PRIMARY">
                    <profile name="" format="AUDIO_FORMAT_PCM_16_BIT"
                            samplingRates="48000"
                            channelMasks="AUDIO_CHANNEL_OUT_STEREO"/>
                </mixPort>
            </mixPorts>
            <devicePorts>
                <devicePort tagName="bus0_phone_out"
                            role="sink"
                            type="AUDIO_DEVICE_OUT_BUS"
                            address="BUS00_PHONE">
                    <profile name="" format="AUDIO_FORMAT_PCM_16_BIT"
                            samplingRates="48000"
                            channelMasks="AUDIO_CHANNEL_OUT_STEREO"/>
                    <gains>
                        <gain name="" mode="AUDIO_GAIN_MODE_JOINT"
                                minValueMB="-8400"
                                maxValueMB="4000"
                                defaultValueMB="0"
                                stepValueMB="100"/>
                    </gains>
                </devicePort>
            </devicePorts>
            <routes>
                <route type="mix" sink="bus0_phone_out"
                       sources="mixport_bus0_phone_out"/>
            </routes>
        </module>
    </modules>
</audioPolicyConfiguration>