Audio pour voitures

Android Automotive OS (AAOS) s'appuie sur la pile audio Android de base pour prendre en charge les cas d'utilisation en tant que système d'infoloisirs 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 sonneries et des avertissements qui ont des exigences strictes en termes de disponibilité et de synchronisation. Bien que l'AAOS fournisse des signaux et des mécanismes pour aider le véhicule à gérer l'audio, c'est finalement le véhicule qui décide des sons à diffuser pour le conducteur et les passagers, en veillant à ce que les sons essentiels à la sécurité et les sons réglementaires soient 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 sélection audio et les événements de touche multimédia pour la source.

Android 11 inclut les modifications suivantes apportées à la prise en charge audio pour les véhicules:

• Sélection automatique de la zone audio en fonction de l'ID utilisateur associé
• Nouveaux usages du système pour prendre en charge les sons spécifiques aux véhicules
• Compatibilité avec la mise au point audio HAL
• Focus audio différé 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 les flux suivants :

Figure 1 : Schéma de l'architecture axée sur les flux

Android gère les sons provenant des applications Android, en les contrôlant et en les acheminant vers les périphériques de sortie au niveau du HAL en fonction du type de son :

• Les flux logiques, appelés sources dans la nomenclature audio de base, sont tagués avec des attributs audio.
• Les flux physiques, appelés "appareils" dans la nomenclature audio de base, ne contiennent aucune information de contexte après le mixage.

Pour plus de fiabilité, les sons externes (provenant de sources indépendantes telles que les sonneries d'avertissement de ceinture de sécurité) sont gérés en dehors d'Android, en dessous du HAL ou même dans du matériel distinct. Les implémentateurs système doivent fournir un mélangeur qui accepte un ou plusieurs flux d'entrée audio à partir d'Android, puis combine ces flux de manière appropriée avec les sources audio externes requises par le véhicule.

L'implémentation HAL et le mixeur externe sont chargés de s'assurer 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 standards (par exemple, AudioManager pour le contrôle de la mise au point ou MediaPlayer pour le streaming) afin d'émettre un ou plusieurs flux logiques de données audio. Ces données peuvent être mono à un seul canal ou surround 7.1, mais elles sont acheminées et traitées comme une seule source. Le flux de l'application est associé à des AudioAttributes qui donnent au système des indications sur la façon dont l'audio doit être exprimé.

Les flux logiques sont envoyés via AudioService et acheminés vers l'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 HAL audio pour le rendu sur le matériel. Dans les applications automobiles, le matériel de rendu peut être un codec local (comme sur les appareils mobiles) ou un processeur distant sur le réseau physique du véhicule. Dans tous les cas, l'implémentation de l'HAL audio a pour fonction de fournir les données d'échantillonnage réelles et de les rendre audibles.

Flux externes

Les flux audio qui ne doivent pas être acheminés via Android (pour des raisons de certification ou de synchronisation) peuvent être envoyés directement au mélangeur externe. À partir d'Android 11, le HAL peut désormais demander la mise au point de ces sons externes pour informer Android afin qu'il puisse prendre les mesures appropriées, comme suspendre les contenus multimédias ou empêcher d'autres éléments d'obtenir la mise au point.

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 la mise au point audio au nom de la source multimédia plutôt qu'au nom du HAL, et répondrait aux notifications de mise au point en démarrant/arrêtant la source externe si nécessaire pour s'adapter au paramètre de mise au point Android. L'application est également chargée de gérer les événements de touche multimédia tels que la lecture/la pause. HwAudioSource est un mécanisme suggéré pour contrôler ces appareils externes.

Périphériques de sortie

Au niveau du HAL audio, le type d'appareil AUDIO_DEVICE_OUT_BUS fournit un périphérique de sortie générique à utiliser dans les systèmes audio des véhicules. L'appareil de bus prend en charge les ports adressables (chaque port étant le point de terminaison d'un flux physique) et devrait être le seul type d'appareil de sortie compatible dans un véhicule.

Une implémentation système peut utiliser un port de bus pour tous les sons Android, auquel cas Android mélange tout et le transmet sous forme de flux. Le HAL peut également 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 mixer et de réduire le volume des différents sons selon les besoins.

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

Entrée micro

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

La source VOICE_RECOGNITION (et plus précisément l'Assistant Google) s'attend à un flux de micro stéréo avec un effet d'annulation de l'écho (le cas échéant), mais aucun autre traitement ne lui est appliqué. Le beamforming doit être effectué par l'Assistant.

Entrée micro multicanal

Pour capturer l'audio d'un appareil comportant plus de deux canaux (stéréo), utilisez un masque d'index de canal plutôt qu'un masque d'index de position (par exemple, 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 n'utilise que 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 visant à 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 peuvent donc être capturées simultanément avec une entrée standard (comme le micro). Les HwAudioSources ne sont pas non plus considérés comme faisant partie des restrictions de capture simultanée.

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

Utilisations audio

AAOS utilise principalement AudioAttributes.AttributeUsages pour le routage, les ajustements du volume et la gestion de la mise au point. Les utilisations représentent la raison pour laquelle le flux est diffusé. Par conséquent, toutes les requêtes de flux et de mise au point audio doivent spécifier un usage pour la lecture audio. Si elle n'est pas définie spécifiquement lors de la création d'un objet AudioAttributes, l'utilisation est définie par défaut sur USAGE_UNKNOWN. Bien que ce comportement soit actuellement traité de la même manière que USAGE_MEDIA, il 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 manière similaire aux utilisations établies précédemment, sauf qu'elles nécessitent des API système à utiliser ainsi que android.permission.MODIFY_AUDIO_ROUTING. Voici les nouveaux usages du système :

• USAGE_EMERGENCY
• USAGE_SAFETY
• USAGE_VEHICLE_STATUS
• USAGE_ANNOUNCEMENT

Pour créer un AudioAttributes avec une utilisation du système, utilisez AudioAttributes.Builder#setSystemUsage au lieu de setUsage. Appeler cette méthode avec une utilisation non système entraînera l'émission d'une exception IllegalArgumentException. De plus, si une utilisation système et une utilisation ont été définies sur un compilateur, une exception IllegalArgumentException est générée lors de la compilation.

Pour vérifier l'utilisation associée à une instance AudioAttributes, appelez AudioAttributes#getSystemUsage. Cette valeur renvoie l'utilisation ou l'utilisation système associée.

Contextes audio

Pour simplifier la configuration de l'audio AAOS, les utilisations similaires ont été regroupées dans CarAudioContext. Ces contextes audio sont utilisés dans l'ensemble de CarAudioService pour définir le routage, les groupes de volume et la gestion de la mise au point audio.

Les contextes audio sous Android 11 sont les suivants :

Mappage entre les contextes audio et les utilisations. Les lignes en surbrillance correspondent aux nouveaux usages du système.

Audio multizone

L'automobile s'accompagne d'un nouvel ensemble de cas d'utilisation concernant les utilisateurs simultanés qui interagissent avec la plate-forme et souhaitent consommer des contenus multimédias distincts. Par exemple, un conducteur peut écouter de la musique dans l'habitacle tandis que les passagers à l'arrière regardent une vidéo YouTube sur l'écran arrière. L'audio multizone permet de diffuser simultanément différentes sources audio dans différentes zones du véhicule.

À partir d'Android 10, l'audio multizone permet aux OEM de configurer l'audio dans des zones distinctes. Chaque zone est un ensemble d'appareils dans le véhicule avec ses propres groupes de volume, sa configuration de routage pour les contextes et sa gestion de la mise au point. De cette manière, la cabine principale peut être configurée en tant que zone audio, tandis que les prises casque de l'écran arrière peuvent être configurées en tant que deuxième zone.

Les zones sont définies dans car_audio_configuration.xml. CarAudioService lit ensuite la configuration et aide AudioService à acheminer les flux audio en fonction de la 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 il est associé, puis, en fonction de l'utilisation, l'appareil auquel AudioFlinger doit acheminer l'audio.

Le focus est également maintenu indépendamment pour chaque zone audio. Cela permet aux applications de différentes zones de produire de l'audio indépendamment, sans interférer les unes avec les autres, tout en respectant les changements de focus dans leur zone. CarZonesAudioFocus dans CarAudioService est chargé de gérer la sélection pour chaque zone.

Figure 2. Configurer l'audio multizone

HAL audio

Les implémentations audio pour l'automobile reposent sur le HAL Android Audio standard, qui inclut 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 le volume pour chaque flux physique.
• IStream.hal : avec les variantes d'entrée et de sortie, gère le streaming des échantillons audio vers et depuis le matériel.

Types d'appareils automobiles

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

Configurer des appareils audio

Les appareils audio visibles par Android doivent être définis dans /audio_policy_configuration.xml, qui comprend les composants suivants:

• nom du module. Compatible avec "primary" (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.
• devicePorts. Contient une liste de descripteurs d'appareils pour tous les appareils d'entrée et de sortie (y compris les appareils connectés en permanence et les appareils amovibles) auxquels vous pouvez accéder à partir de ce module.
• Pour chaque appareil de sortie, vous pouvez définir un contrôle du gain composé de valeurs min/max/par défaut/par incrément en millibel (1 millibel = 1/100 dB = 1/1 000 bel).
• L'attribut d'adresse d'une instance devicePort permet de trouver l'appareil, même s'il existe plusieurs appareils du même type que AUDIO_DEVICE_OUT_BUS.
• mixPorts. Contient la 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.
• routes. Définit une liste de connexions possibles entre les appareils d'entrée et de sortie ou entre le flux et l'appareil.

L'exemple suivant définit un bus0_phone_out d'appareil de sortie dans lequel tous les flux audio Android sont mélangés par mixer_bus0_phone_out. L'itinéraire prend le flux de sortie de mixer_bus0_phone_out vers l'appareil 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>