Audio pour voitures

Android Automotive OS (AAOS) s'appuie sur la pile audio principale d'Android pour prendre en charge les cas d'utilisation du système d'infoloisirs dans un véhicule. AAOS est responsable des sons d'infoloisirs (c'est-à-dire des médias, de la navigation et mais n'est pas directement responsable des signaux sonores et des avertissements de disponibilité et de délais stricts. Alors qu'AAOS fournit des signaux et pour aider le véhicule à gérer l'audio. afin de déterminer quels sons doivent être émis pour le conducteur et des passagers, en veillant à ce que les sons critiques de sécurité et les sons réglementaires sans interruption.

Comme Android gère l'expérience multimédia du véhicule, les sources multimédias externes comme le tuner radio, doivent être représentés par des applications capables de gérer l'audio le focus et les événements clés média pour la source.

Android 11 inclut les modifications suivantes apportées au son lié à l'automobile assistance technique:

• Sélection automatique des zones audio en fonction de l'ID utilisateur associé
• Nouvelles utilisations du système pour prendre en charge les sons propres aux automobiles
• Compatibilité avec la priorité audio HAL
• Priorité audio différée pour les flux non temporaires
• Paramètre utilisateur permettant de contrôler l'interaction entre la navigation et les appels

Sons et diffusions Android

Les systèmes audio d'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 applis Android et contrôle ces applis et acheminer leurs sons vers les périphériques de sortie du HAL en fonction du type son:

• Flux logiques, appelés sources de l'audio principal sont associés aux attributs audio.
• Les flux physiques, appelés "appareils dans l'audio principal" sans aucune information de contexte après le mélange.

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

L'implémentation de HAL et le mélangeur externe sont chargés de garantir que les sons extérieurs essentiels à la sécurité sont entendus et pour le mixage dans le et les acheminer vers les haut-parleurs appropriés.

Sons Android

Les applications peuvent avoir un ou plusieurs lecteurs qui interagissent via la version standard d'Android Les API (par exemple, AudioManager pour la mise au point ou MediaPlayer pour le streaming) afin d'émettre un ou plusieurs flux logiques de données audio. Ces données peut être un canal mono ou surround 7.1, mais est acheminé et traité comme source unique. Le flux d'application est associé à des AudioAttributes qui donnent au système des indications sur la façon dont le contenu 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 correspondant à la sortie d'un mélangeur dans AudioFlinger. Une fois les attributs audio mélangés à un flux physique, elles ne sont plus disponibles.

Chaque flux physique est ensuite transmis au HAL audio pour être rendu le matériel. Dans les applications de voiture, le matériel de rendu peut être des codecs locaux. (semblable aux appareils mobiles), soit à l'aide d'un processeur à distance réseau. Dans tous les cas, la mise en œuvre de l'audio HAL est chargée de fournir de données d'échantillon réelles et de les rendre audibles.

Flux externes

les flux audio qui ne doivent pas être acheminés via Android (pour les certifications ou des motifs) peuvent être envoyés directement au mélangeur externe. Depuis Android 11, le HAL peut désormais demander la priorité à ces sons externes afin d'informer Android afin qu'il puisse prendre les mesures appropriées, par exemple mettre en pause un contenu multimédia ou empêcher aux autres de se concentrer.

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

Périphériques de sortie

Au niveau de l'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 d'un véhicule. Le bus périphérique prend en charge les ports adressables (où chaque port est le point de terminaison d'un flux physique) et devrait être le seul type d'appareil de sortie compatible un véhicule.

Une implémentation système peut utiliser un seul port de bus pour tous les sons Android, dans Dans ce cas, Android les rassemble dans un seul flux. Le HAL peut également fournir un port de bus pour chaque CarAudioContext pour permettre diffusion simultanée de tout type de son. Cela permet au HAL pour mixer les différents sons selon vos besoins.

L'attribution de contextes audio aux périphériques de sortie s'effectue car_audio_configuration.xml

Entrée micro

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

La source VOICE_RECOGNITION (en particulier l'Assistant Google) s'attend à un flux de micro stéréo un effet d'annulation de l'écho (le cas échéant), mais aucun autre traitement ne lui est appliqué. Le Beamforming est censé être effectué par l'Assistant.

Entrée micro multicanal

Pour enregistrer du contenu audio à partir d'un appareil disposant de plus de deux canaux (stéréo), utilisez un le masque d'index du canal au lieu du masque d'index positionnel (comme 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éfinies, AudioRecord n'utilise que la valeur définie par setChannelMask (deux canaux maximum).

Capture simultanée

À partir d'Android 10, le framework Android prend en charge la capture simultanée d'entrées, mais avec des restrictions pour protéger la confidentialité de l'utilisateur. Dans le cadre de ces restrictions, des sources virtuelles AUDIO_SOURCE_FM_TUNER sont ignorés et peuvent donc être capturées simultanément avec une entrée standard (comme le micro). Les HwAudioSources ne sont pas non plus prises en compte des restrictions de capture.

Applis conçues pour fonctionner avec les appareils AUDIO_DEVICE_IN_BUS ou avec les appareils AUDIO_DEVICE_IN_FM_TUNER secondaires doivent s'appuyer en identifiant ces appareils et en utilisant AudioRecord.setPreferredDevice() pour contourner la logique de sélection de la source par défaut d'Android.

Utilisations de l'audio

AAOS utilise principalement AudioAttributes.AttributeUsages pour le routage, les réglages de volume et la gestion du focus. Les utilisations sont un représentation du « pourquoi » pendant la lecture du flux. Par conséquent, tous les flux et les requêtes de ciblage audio doivent spécifier une utilisation pour la lecture audio. Quand ? n'est pas spécifiquement défini lors de la création d'un objet AudioAttributes, l'utilisation sera défini par défaut sur USAGE_UNKNOWN. Bien qu'il soit actuellement traité de la même manière comme USAGE_MEDIA, ce comportement ne doit pas être utilisé pour les contenus lecture.

Utilisations du système

Dans Android 11, les utilisations du système ont été introduites. Ces usages se comportent de façon semblable aux utilisations précédentes, sauf qu'elles nécessitent des API système à utiliser, ainsi que android.permission.MODIFY_AUDIO_ROUTING. Les nouvelles systèmes d'exploitation sont les suivants:

• 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. Appeler cette méthode avec une utilisation hors système entraînera la génération d'une erreur IllegalArgumentException. Par ailleurs, si l'utilisation du système et l'utilisation ont été définies sur un compilateur, une exception IllegalArgumentException lors de la compilation.

Vérifier l'utilisation associée à un AudioAttributes appelez AudioAttributes#getSystemUsage. Renvoie l'utilisation ou l'utilisation du système qui est 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 tout au long CarAudioService pour définir le routage, les groupes de volumes et le ciblage audio gestion de la sécurité.

Les contextes audio sous Android 11 sont les suivants:

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

Audio multizone

L'automobile s'accompagne d'un nouvel ensemble de cas d'utilisation impliquant des utilisateurs simultanés interagissant avec la plate-forme et en cherchant à consommer d'autres contenus multimédias. Pour Exemple : un conducteur peut diffuser de la musique dans la cabine, tandis que les passagers sont installés sur le siège arrière. regardent une vidéo YouTube sur l'écran arrière. L'audio multizone permet en permettant la lecture simultanée de plusieurs sources audio 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 constituée d'un ensemble d'appareils dans le véhicule. avec ses propres groupes de volumes, une configuration de routage pour les contextes gestion de la sécurité. Ainsi, l'antenne principale peut être configurée comme une seule piste audio zone, tandis que les connecteurs casque de l'écran arrière doivent être configurés comme une 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 qui leur est associée. Chaque zone définit toujours des règles de routage en fonction des contextes et de l'UID des applications. Lorsqu'un joueur est créé, CarAudioService détermine la zone pour laquelle le joueur se trouve auquel est associé l'AudioFlinger, puis en fonction de l'utilisation. doit rediriger l'audio.

La mise au point est également maintenue indépendamment pour chaque zone audio. Cela permet des applications dans différentes zones pour produire indépendamment du son interférence les uns avec les autres tout en faisant en sorte que les applications respectent toujours les modifications se concentrent dans leur zone. CarZonesAudioFocus dans la plage CarAudioService est responsable de la gestion de l'attention pour chaque dans la zone.

Figure 2. Configurer l'audio multizone

HAL audio

Les implémentations audio pour voitures s'appuient sur le HAL audio standard d'Android, ce qui inclut les éléments suivants:

• IDevice.hal crée des flux d'entrée et de sortie, gère le volume principal et les coupures de son, et utilise: <ph type="x-smartling-placeholder">
  </ph>
  • createAudioPatch Créer des correctifs externes entre les appareils
  • IDevice.setAudioPortConfig() afin de fournir un volume pour chaque flux physique.
• IStream.hal En plus des variantes d'entrée et de sortie, gère le flux 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.

Configurer des appareils audio

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

• nom du module. Prend en charge le mode "principal" (pour les cas d'utilisation dans le secteur automobile), "A2DP", "remote_submix" et "USB". Nom du module et contenu audio correspondant le pilote doit être compilé dans audio.primary.$(variant).so.
• devicePorts. Contient une liste de descripteurs d'appareil pour toutes les entrées et sorties (y compris les périphériques connectés en permanence et les périphériques amovibles) qui peuvent être accessibles à partir de ce module.
• Pour chaque périphérique de sortie, vous pouvez définir un contrôle de gain composé de les valeurs min/max/par défaut/pas en millibel (1 millibel = 1/100 dB = 1/1 000 bel).
• L'attribut d'adresse d'une instance devicePort peut être utilisé pour trouver même si plusieurs appareils sont associés au même type d'appareil AUDIO_DEVICE_OUT_BUS
• "MixPorts". Contient une liste de tous les flux de sortie et d'entrée exposés par 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 l'entrée et la sortie appareils, ou entre le flux et l'appareil.

L'exemple suivant définit un périphérique de sortie "bus0_phone_out" dans lequel tous Les flux audio Android sont mélangés par mixer_bus0_phone_out. L'itinéraire prend la 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>