Audio automobile

Android Automotive OS (AAOS) s'appuie sur la pile audio Android de base pour prendre en charge les cas d'utilisation liés au fonctionnement en tant que système d'infodivertissement dans un véhicule. AAOS est responsable des sons d'infodivertissement (c'est-à-dire les médias, la navigation et les communications), mais n'est pas directement responsable des carillons et des avertissements qui ont des exigences strictes en matière de disponibilité et de synchronisation. Bien que l'AAOS fournisse des signaux et des mécanismes pour aider le véhicule à gérer le son, en fin de compte, c'est au véhicule de décider quels sons doivent être émis pour le conducteur et les passagers, garantissant ainsi que les sons critiques pour la sécurité et les sons réglementaires sont correctement entendus sans interruption.

Comme Android gère l'expérience multimédia du véhicule, les sources multimédias externes telles que le tuner radio doivent être représentées par des applications, qui peuvent gérer la mise au point audio et les événements clés multimédia pour la source.

Android 11 inclut les modifications suivantes dans la prise en charge audio liée à l'automobile :

• Sélection automatique de la zone audio en fonction de l'ID utilisateur associé
• Nouvelles utilisations du système pour prendre en charge les sons spécifiques à l'automobile
• Prise en charge de la mise au point audio HAL
• Focus audio retardé pour les flux non transitoires
• Paramètre utilisateur pour contrôler l'interaction entre la navigation et les appels

Sons et flux Android

Les systèmes audio automobiles gèrent les sons et flux suivants :

Figure 1. Diagramme d'architecture centrée sur le flux

Android gère les sons provenant des applications Android, contrôle ces applications et achemine leurs sons vers les périphériques de sortie du HAL en fonction du type de son :

• Les flux logiques , appelés sources dans la nomenclature audio principale, sont étiquetés avec des attributs audio .
• Les flux physiques , appelés périphériques dans la nomenclature audio principale, n'ont aucune information contextuelle après le mixage.

Pour des raisons de fiabilité, les sons externes (provenant de sources indépendantes telles que les carillons d'avertissement de ceinture de sécurité) sont gérés en dehors d'Android, sous le HAL ou même dans un matériel séparé. Les responsables de la mise en œuvre du système doivent fournir un mélangeur qui accepte un ou plusieurs flux sonores provenant d'Android, puis combine ces flux de manière appropriée avec les sources sonores externes requises par le véhicule.

L'implémentation HAL et le mixeur externe sont chargés de garantir que les sons externes critiques pour la sécurité sont entendus, de mixer les flux fournis par Android et de les acheminer vers des haut-parleurs appropriés.

Sons Android

Les applications peuvent avoir un ou plusieurs lecteurs qui interagissent via les API Android standard (par exemple, AudioManager pour le contrôle de la mise au point ou MediaPlayer pour le streaming) pour émettre un ou plusieurs flux logiques de données audio. Ces données peuvent être monocanales ou surround 7.1, mais sont acheminées et traitées comme une source unique. Le flux de l'application est associé à des AudioAttributes qui donnent au système des indications sur la manière dont l'audio doit être exprimé.

Les flux logiques sont envoyés via AudioService et acheminés vers un (et un seul) des flux de sortie physiques disponibles, chacun étant la sortie d'un mélangeur dans AudioFlinger. Une fois les attributs audio mixés dans un flux physique, ils ne sont plus disponibles.

Chaque flux physique est ensuite transmis au Audio HAL pour un rendu sur le matériel. Dans les applications automobiles, le matériel de rendu peut être constitué de codecs locaux (similaires aux appareils mobiles) ou d'un processeur distant sur le réseau physique du véhicule. Quoi qu'il en soit, c'est le travail de l'implémentation Audio HAL de fournir les échantillons de données réels et de les rendre audibles.

Flux externes

Les flux sonores qui ne doivent pas être acheminés via Android (pour des raisons de certification ou de timing) peuvent être envoyés directement au mixeur externe. Depuis Android 11, HAL est désormais en mesure de demander le focus sur ces sons externes afin d'informer Android afin qu'il puisse prendre les mesures appropriées telles que mettre le média en pause ou empêcher les autres de se concentrer.

Si les flux externes sont des sources multimédias qui doivent interagir avec l'environnement sonore généré par Android (par exemple, arrêter la lecture MP3 lorsqu'un tuner externe est activé), ces flux externes doivent être représentés par une application Android. Une telle application demanderait le focus audio au nom de la source multimédia au lieu du HAL, et répondrait aux notifications de focus en démarrant/arrêtant la source externe si nécessaire pour s'adapter à la politique de focus Android. L'application est également responsable de la gestion des événements clés multimédias tels que la lecture/pause. Un mécanisme suggéré pour contrôler ces périphériques externes est HwAudioSource .

Des dispositifs de sortie

Au niveau Audio HAL, le type de périphérique AUDIO_DEVICE_OUT_BUS fournit un périphérique de sortie générique à utiliser dans les systèmes audio des véhicules. Le périphérique de bus prend en charge les ports adressables (où chaque port est le point final d'un flux physique) et devrait être le seul type de périphérique de sortie pris en charge dans un véhicule.

Une implémentation de système peut utiliser un port de bus pour tous les sons Android, auquel cas Android mélange le tout et le diffuse sous la forme d'un seul flux. Alternativement, le HAL peut fournir un port de bus pour chaque CarAudioContext afin de permettre la diffusion simultanée de n'importe quel type de son. Cela permet à l'implémentation HAL de mélanger et d'atténuer les différents sons comme vous le souhaitez.

L'attribution des contextes audio aux périphériques de sortie se fait via car_audio_configuration.xml .

Entrée micro

Lors de la capture audio, Audio HAL reçoit un appel openInputStream qui inclut un argument AudioSource indiquant comment l'entrée du microphone doit être traitée.

La source VOICE_RECOGNITION (en particulier l'Assistant Google) attend un flux de microphone stéréo qui a un effet d'annulation d'écho (si disponible) mais aucun autre traitement ne lui est appliqué. La formation de faisceaux devrait être effectuée par l'assistant.

Entrée microphone multicanal

Pour capturer l'audio d'un appareil avec plus de deux canaux (stéréo), utilisez un masque d'index de canal au lieu d'un masque d'index de position (tel que CHANNEL_IN_LEFT ). Exemple:

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);

Lorsque setChannelMask et setChannelIndexMask sont définis, AudioRecord utilise uniquement la valeur définie par setChannelMask (maximum de deux canaux).

Capture simultanée

Depuis Android 10, le framework Android prend en charge la capture simultanée des entrées, mais avec des restrictions pour protéger la confidentialité de l'utilisateur. Dans le cadre de ces restrictions, les sources virtuelles telles que AUDIO_SOURCE_FM_TUNER sont ignorées et, en tant que telles, peuvent être capturées simultanément avec une entrée normale (telle que le microphone). HwAudioSources ne sont pas non plus considérées comme faisant partie des restrictions de capture simultanée.

Les applications conçues pour fonctionner avec des appareils AUDIO_DEVICE_IN_BUS ou avec des appareils AUDIO_DEVICE_IN_FM_TUNER secondaires doivent s'appuyer sur l'identification explicite de ces appareils et sur l'utilisation AudioRecord.setPreferredDevice() pour contourner la logique de sélection de source par défaut d'Android.

Utilisations audio

AAOS utilise principalement AudioAttributes.AttributeUsages pour le routage, les réglages du volume et la gestion de la mise au point. Les utilisations sont une représentation du « pourquoi » le flux est lu. Par conséquent, tous les flux et demandes de focus audio doivent spécifier une utilisation pour leur lecture audio. Lorsqu'elle n'est pas spécifiquement définie lors de la création d'un objet AudioAttributes, l'utilisation sera par défaut USAGE_UNKNOWN . Bien que ce soit actuellement traité de la même manière que USAGE_MEDIA , ce comportement ne doit pas être utilisé pour la lecture multimédia.

Utilisations du système

Dans Android 11, les utilisations du système ont été introduites. Ces utilisations se comportent de la même manière que les utilisations précédemment établies, sauf qu'elles nécessitent l'utilisation d'API système ainsi que de android.permission.MODIFY_AUDIO_ROUTING . Les nouvelles utilisations du système sont :

• USAGE_EMERGENCY
• USAGE_SAFETY
• USAGE_VEHICLE_STATUS
• USAGE_ANNOUNCEMENT

Pour construire un AudioAttributes avec une utilisation du système, utilisez AudioAttributes.Builder#setSystemUsage au lieu de setUsage . L’appel de cette méthode avec une utilisation non système entraînera la levée d’une IllegalArgumentException . De plus, si une utilisation du système et une utilisation ont été définies sur un générateur, celui-ci lancera une IllegalArgumentException lors de la construction.

Pour vérifier quelle utilisation est associée à une instance AudioAttributes , appelez AudioAttributes#getSystemUsage . Cela renvoie l'utilisation ou l'utilisation du système associée.

Contextes audio

Pour simplifier la configuration de l'audio AAOS, des utilisations similaires ont été regroupées dans CarAudioContext . Ces contextes audio sont utilisés dans CarAudioService pour définir le routage, les groupes de volumes et la gestion du focus audio.

Les contextes audio dans Android 11 sont :

Mappage entre contextes audio et usages. Les lignes en surbrillance concernent les nouvelles utilisations du système .

Audio multizone

L’automobile s’accompagne d’un nouvel ensemble de cas d’utilisation autour d’utilisateurs simultanés interagissant avec la plate-forme et cherchant à consommer des médias distincts. Par exemple, un conducteur peut écouter de la musique dans la cabine pendant que les passagers assis à l'arrière regardent une vidéo YouTube sur l'écran arrière. L'audio multizone permet cela en permettant à différentes sources audio de jouer simultanément dans différentes zones du véhicule.

L'audio multizone à partir d'Android 10 permet aux OEM de configurer l'audio dans des zones distinctes. Chaque zone est un ensemble d'appareils au sein du véhicule avec ses propres groupes de volumes, sa propre configuration de routage pour les contextes et sa gestion du focus. De cette manière, la cabine principale pourrait être configurée comme une zone audio, tandis que les prises casque de l'écran arrière pourraient être configurées comme une deuxième zone.

Les zones sont définies dans le cadre de car_audio_configuration.xml . CarAudioService lit ensuite la configuration et aide AudioService à acheminer les flux audio en fonction de leur zone associée. Chaque zone définit toujours des règles de routage en fonction des contextes et de l'uid des applications. Lorsqu'un lecteur est créé, CarAudioService détermine à quelle zone le lecteur est associé, puis, en fonction de l'utilisation, vers quel appareil AudioFlinger doit acheminer l'audio.

La mise au point est également maintenue indépendamment pour chaque zone audio. Cela permet aux applications situées dans différentes zones de produire de l'audio indépendamment sans interférer les unes avec les autres, tout en permettant aux applications de toujours respecter les changements de focus au sein de leur zone. CarZonesAudioFocus au sein CarAudioService est responsable de la gestion du focus pour chaque zone.

Figure 2. Configurer l'audio multizone

AudioHAL

Les implémentations audio automobiles s'appuient sur la norme Android Audio HAL, qui comprend les éléments suivants :

• IDevice.hal . Crée des flux d'entrée et de sortie, gère le volume principal et la mise en sourdine et utilise :
  • createAudioPatch . Pour créer des correctifs externes-externes entre les appareils.
  • IDevice.setAudioPortConfig() pour fournir du volume pour chaque flux physique.
• IStream.hal . Outre les variantes d'entrée et de sortie, gère le streaming d'échantillons audio vers et depuis le matériel.

Types d'appareils automobiles

Les types d'appareils suivants sont pertinents pour les plates-formes automobiles.

Configuration des périphériques audio

Les périphériques audio visibles sur Android doivent être définis dans /audio_policy_configuration.xml , qui comprend les composants suivants :

• nom du module. Prend en charge « primaire » (utilisé pour les cas d'utilisation automobile), « A2DP », « remote_submix » et « USB ». Le nom du module et le pilote audio correspondant doivent être compilés en audio.primary.$(variant).so .
• ports de périphérique. Contient une liste de descripteurs de périphériques pour tous les périphériques d'entrée et de sortie (y compris les périphériques connectés en permanence et les périphériques amovibles) accessibles à partir de ce module.
• Pour chaque périphérique de sortie, vous pouvez définir un contrôle de gain composé de valeurs min/max/par défaut/pas en millibel (1 millibel = 1/100 dB = 1/1000 bel).
• L'attribut d'adresse sur une instance de devicePort peut être utilisé pour rechercher le périphérique, même s'il existe plusieurs périphériques avec le même type de périphérique que AUDIO_DEVICE_OUT_BUS .
• mixPorts. Contient une liste de tous les flux de sortie et d’entrée exposés par le HAL audio. Chaque instance mixPort peut être considérée comme un flux physique vers Android AudioService.
• itinéraires. Définit une liste de connexions possibles entre les périphériques d'entrée et de sortie ou entre le flux et le périphérique.

L'exemple suivant définit un périphérique de sortie bus0_phone_out dans lequel tous les flux audio Android sont mixés par mixer_bus0_phone_out. La route amène le flux de sortie de mixer_bus0_phone_out vers le périphérique 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>