Configurer les règles audio

La version Android 10 inclut une refactorisation importante du gestionnaire de règles audio pour offrir plus de flexibilité et prendre en charge des cas d'utilisation automobiles complexes :

  • Stratégies de routage spécifiques aux OEM.
  • Groupes de volume personnalisables pour les groupes d'anciens types de flux utilisant les mêmes courbes de volume.
  • Stratégies de routage déclarées par le moteur de règles audio au lieu d'être codées en dur.
  • Courbes de volume et groupes gérés par le moteur de règles audio.
  • Refactoring interne préparant une future séparation entre le code commun et le code configurable, et offrant une gestion plus riche des périphériques audio. Par exemple, l'utilisation de toutes les propriétés de l'appareil, et pas seulement de son type, dans les règles de stratégie.

Android 7.0 a introduit un format de fichier de configuration de la stratégie audio (XML) pour décrire votre topologie audio.

Les versions précédentes d'Android nécessitaient l'utilisation de device/<company>/<device>/audio/audio_policy.conf pour déclarer les périphériques audio présents sur votre produit (vous pouvez voir un exemple de ce fichier pour le matériel audio Galaxy Nexus dans device/samsung/tuna/audio/audio_policy.conf). Toutefois, CONF est un format propriétaire simple qui est trop limité pour décrire des topologies complexes pour des secteurs verticaux tels que les téléviseurs et les automobiles.

Android 7.0 a abandonné audio_policy.conf et ajouté la prise en charge de la définition d'une topologie audio à l'aide d'un format de fichier XML plus lisible, doté d'un large éventail d'outils d'édition et d'analyse, et suffisamment flexible pour décrire des topologies audio complexes. Android 7.0 utilise l'indicateur de compilation USE_XML_AUDIO_POLICY_CONF pour choisir le format XML des fichiers de configuration.

Avantages du format XML

Comme dans le fichier CONF, le fichier XML permet de définir le nombre et les types de profils de flux de sortie et d'entrée, les appareils utilisables pour la lecture et la capture, ainsi que les attributs audio. En outre, le format XML offre les améliorations suivantes :

  • Dans Android 10, plusieurs applications d'enregistrement peuvent être actives simultanément.
    • Le démarrage d'un enregistrement n'est jamais refusé en raison d'une situation de concurrence.
    • Le rappel registerAudioRecordingCallback(AudioManager.AudioRecordingCallback cb) informe les clients des modifications apportées au chemin de capture.
  • Dans les situations suivantes, un client reçoit des échantillons audio silencieux :
    • Un cas d'utilisation sensible en termes de confidentialité (par exemple, VOICE_COMMUNICATION) est actif.
    • Le client ne dispose pas de service de premier plan ni d'UI de premier plan.
    • Les rôles spéciaux sont reconnus par le règlement :
      • Service d'accessibilité : peut enregistrer même si un cas d'utilisation sensible en termes de confidentialité est actif.
      • Assistant : considéré comme sensible en termes de confidentialité si l'UI est au premier plan.
  • Les profils audio ont une structure semblable à celle des descripteurs audio simples HDMI, ce qui permet d'utiliser un ensemble différent de fréquences d'échantillonnage/masques de canaux pour chaque format audio.
  • Des définitions explicites sont fournies pour toutes les connexions possibles entre les appareils et les flux. Auparavant, une règle implicite permettait de connecter tous les appareils associés au même module HAL, ce qui empêchait la stratégie audio de contrôler les connexions demandées avec les API de patch audio. Dans le format XML, la description de la topologie définit les limites de connexion.
  • La prise en charge de includes évite de répéter les définitions standards A2DP, USB ou de soumission de redirection.
  • Les courbes de volume sont personnalisables. Auparavant, les tables de volume étaient codées en dur. Au format XML, les tableaux de volumes sont décrits et peuvent être personnalisés.

Le modèle frameworks/av/services/audiopolicy/config/audio_policy_configuration.xml montre comment utiliser plusieurs de ces fonctionnalités.

Format et emplacement du fichier

Le nouveau fichier de configuration des règles audio est audio_policy_configuration.xml et se trouve dans /system/etc. Les exemples suivants montrent une configuration simple de la stratégie audio au format de fichier XML pour Android 12 et pour les versions antérieures à Android 12.

La structure de premier niveau contient des modules qui correspondent à chaque module matériel audio HAL, où chaque module comporte une liste de ports de mixage, de ports d'appareil et de routes :

  • Les ports de mixage décrivent les profils de configuration possibles pour les flux qui peuvent être ouverts au niveau de la couche d'abstraction matérielle audio pour la lecture et la capture.
  • Les ports de l'appareil décrivent les appareils qui peuvent être connectés avec leur type (et éventuellement leur adresse et leurs propriétés audio, le cas échéant).
  • Routes est séparé du descripteur de port de mixage, ce qui permet de décrire les routes d'appareil à appareil ou de flux à appareil.

Les tables de volume sont des listes simples de points définissant la courbe utilisée pour traduire un index d'interface utilisateur en volume en dB. Un fichier d'inclusion distinct fournit des courbes par défaut, mais chaque courbe pour un cas d'utilisation et une catégorie d'appareil donnés peut être remplacée.

Inclusions de fichiers

La méthode XML Inclusions (XInclude) peut être utilisée pour inclure des informations de configuration de la stratégie audio situées dans d'autres fichiers XML. Tous les fichiers inclus doivent suivre la structure décrite ci-dessus, avec les restrictions suivantes :

  • Les fichiers ne peuvent contenir que des éléments de premier niveau.
  • Les fichiers ne peuvent pas contenir d'éléments XInclude.

Utilisez "includes" pour éviter de copier les informations de configuration du module HAL audio standard Android Open Source Project (AOSP) dans tous les fichiers de configuration de la stratégie audio (ce qui est source d'erreurs). Un fichier XML de configuration standard des règles audio est fourni pour les HAL audio suivants :

  • A2DP : a2dp_audio_policy_configuration.xml
  • Sous-mix de réacheminement : rsubmix_audio_policy_configuration.xml
  • USB : usb_audio_policy_configuration.xml

Organisation du code des règles audio

AudioPolicyManager.cpp est divisé en plusieurs modules pour faciliter la maintenance et la configuration. L'organisation de frameworks/av/services/audiopolicy inclut les modules suivants.

Module Description
/managerdefault Inclut les interfaces génériques et l'implémentation du comportement commun à toutes les applications. Semblable à AudioPolicyManager.cpp, mais avec la fonctionnalité du moteur et les concepts courants abstraits.
/common Définit les classes de base (par exemple, les structures de données pour les profils de flux audio d'entrée/sortie, les descripteurs de périphériques audio, les correctifs audio et les ports audio). Auparavant, cette valeur était définie dans AudioPolicyManager.cpp.
/engine

Implémente les règles qui définissent l'appareil et les volumes à utiliser pour un cas d'utilisation donné. Il implémente une interface standard avec la partie générique, par exemple pour obtenir l'appareil approprié pour un cas d'utilisation de lecture ou de capture donné, ou pour définir des appareils connectés ou un état externe (c'est-à-dire un état d'appel d'utilisation forcée) qui peut modifier la décision de routage.

Disponible en deux versions : configurable et par défaut. Pour savoir comment sélectionner la version, consultez Configuration à l'aide du framework de paramètres.
/engineconfigurable Implémentation du moteur de règles qui s'appuie sur le framework de paramètres (voir ci-dessous). La configuration est basée sur le framework de paramètres, et la règle est définie par des fichiers XML.
/enginedefault Implémentation du moteur de règles basée sur les implémentations précédentes d'Android Audio Policy Manager. Il s'agit de la valeur par défaut. Elle inclut des règles codées en dur qui correspondent aux implémentations Nexus et AOSP.
/service Inclut les interfaces de binder, l'implémentation du threading et du verrouillage avec l'interface du reste du framework.

Configuration à l'aide du framework de paramètres

Le code de règles audio est organisé pour être facile à comprendre et à gérer, tout en prenant en charge une règle audio entièrement définie par des fichiers de configuration. La conception de l'organisation et de la stratégie audio est basée sur le framework de paramètres d'Intel, un framework basé sur des règles et des plug-ins pour la gestion des paramètres.

L'utilisation de la stratégie audio configurable permet aux fournisseurs et aux OEM de :

  • Décrivez la structure et les paramètres d'un système en XML.
  • Écrivez (en C++) ou réutilisez un backend (plug-in) pour accéder aux paramètres décrits.
  • Définissez (en XML ou dans un langage spécifique au domaine) les conditions/règles selon lesquelles un paramètre donné doit prendre une valeur donnée.

AOSP inclut un exemple de fichier de configuration de règles audio qui utilise le framework de paramètres à l'adresse Frameworks/av/services/audiopolicy/engineconfigurable/parameter-framework/example/Settings/PolicyConfigurableDomains.xml. Pour en savoir plus, consultez la documentation Intel sur le framework de paramètres.

Dans Android 10 ou une version antérieure, la stratégie audio configurable est sélectionnée à l'aide de l'option de compilation USE_CONFIGURABLE_AUDIO_POLICY. Dans Android 11 ou version ultérieure, la version du moteur de règles audio est sélectionnée dans le fichier audio_policy_configuration.xml. Pour sélectionner le moteur de règles audio configurable, définissez la valeur de l'attribut engine_library de l'élément globalConfiguration sur configurable, comme dans l'exemple suivant :

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

API de routage de la stratégie audio

Android 6.0 a introduit une API publique d'énumération et de sélection qui repose sur l'infrastructure de ports/patchs audio et permet aux développeurs d'applications d'indiquer une préférence pour une sortie ou une entrée d'appareil spécifique pour les enregistrements ou pistes audio connectés.

Dans Android 7.0, l'API d'énumération et de sélection est validée par les tests CTS et étendue pour inclure le routage des flux audio natifs C/C++ (OpenSL ES). Le routage des flux natifs continue d'être effectué en Java, avec l'ajout d'une interface AudioRouting qui remplace, combine et rend obsolètes les méthodes de routage explicites spécifiques aux classes AudioTrack et AudioRecord.

Pour en savoir plus sur l'API d'énumération et de sélection, consultez les interfaces de configuration Android et OpenSLES_AndroidConfiguration.h. Pour en savoir plus sur le routage audio, consultez AudioRouting.

Assistance multicanal

Si votre matériel et votre pilote sont compatibles avec l'audio multicanal via HDMI, vous pouvez envoyer le flux audio directement au matériel audio (cela contourne le mixeur AudioFlinger, de sorte qu'il n'est pas mixé en deux canaux). Le HAL audio doit indiquer si un profil de flux de sortie est compatible avec les fonctionnalités audio multicanaux. Si la HAL expose ses capacités, le gestionnaire de règles par défaut autorise la lecture multicanal via HDMI. Pour en savoir plus sur l'implémentation, consultez device/samsung/tuna/audio/audio_hw.c.

Pour indiquer que votre produit contient une sortie audio multicanal, modifiez le fichier de configuration de la politique audio afin de décrire la sortie multicanal de votre produit. L'exemple suivant tiré de frameworks/av/services/audiopolicy/config/primary_audio_policy_configuration_tv.xml montre un masque de canal dynamique, ce qui signifie que le gestionnaire de règles audio interroge les masques de canal compatibles avec le récepteur HDMI après la connexion.

Vous pouvez également spécifier un masque de canal statique tel que AUDIO_CHANNEL_OUT_5POINT1. Le mixeur d'AudioFlinger réduit automatiquement le contenu au format stéréo lorsqu'il est envoyé à un appareil audio qui ne prend pas en charge l'audio multicanal.

Codecs multimédias

Assurez-vous que les codecs audio compatibles avec votre matériel et vos pilotes sont correctement déclarés pour votre produit. Pour en savoir plus, consultez Exposing Codecs to the Framework (Exposer les codecs au framework).