Configuration des politiques audio

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

La version Android 10 inclut une refonte importante du gestionnaire de règles audio afin d'offrir plus de flexibilité pour prendre en charge les cas d'utilisation automobile complexes :

  • Stratégies de routage spécifiques aux OEM.
  • Groupes de volumes personnalisables pour les groupes de types de flux hérités utilisant les mêmes courbes de volume.
  • Stratégies de routage déclarées par le moteur de politique audio au lieu d'être codées en dur.
  • Courbes et groupes de volume gérés par le moteur de politique audio.
  • Refactoring interne préparant une future séparation entre code commun et 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 son type dans les règles de stratégie.

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

Les versions précédentes d'Android nécessitaient d'utiliser 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 ). Cependant, CONF est un format propriétaire simple qui est trop limité pour décrire des topologies complexes pour des secteurs verticaux comme les téléviseurs et les automobiles.

Android 7.0 a abandonné audio_policy.conf et a ajouté la prise en charge de la définition d'une topologie audio à l'aide d'un format de fichier XML plus lisible par l'homme, 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 construction 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 périphériques utilisables pour la lecture et la capture, et les attributs audio. De plus, le format XML offre les améliorations suivantes :

  • Dans Android 10, plusieurs applications d'enregistrement actives sont autorisées simultanément.
    • Le début de l'enregistrement n'est jamais rejeté en raison d'une situation de concurrence.
    • Le rappel registerAudioRecordingCallback(AudioManager.AudioRecordingCallback cb) informe les clients des changements de chemin de capture.
  • Dans les situations suivantes, un client obtient des échantillons audio silencieux :
    • Un cas d'utilisation sensible à la confidentialité (par exemple, VOICE_COMMUNICATION ) est actif.
    • Le client n'a pas de service ou d'interface utilisateur de premier plan.
    • Les rôles spéciaux sont reconnus par la politique :
      • Service d'accessibilité : peut enregistrer même si un cas d'utilisation sensible à la confidentialité est actif.
      • Assistant : Considéré comme sensible à la confidentialité si l'interface utilisateur est en haut.
  • Les profils audio ont une structure similaire aux descripteurs audio simples HDMI, permettant un ensemble différent de taux d'échantillonnage/masques de canaux pour chaque format audio.
  • Il existe des définitions explicites pour toutes les connexions possibles entre les appareils et les flux. Auparavant, une règle implicite permettait de connecter tous les appareils attachés au même module HAL, empêchant la politique audio de contrôler les connexions demandées avec les API de patch audio. Au format XML, la description de la topologie définit les limitations de connexion.
  • La prise en charge des inclusions évite de répéter les définitions de soumission A2DP, USB ou de réacheminement standard.
  • Les courbes de volume sont personnalisables. Auparavant, les tables de volume étaient codées en dur. Au format XML, les tables de volume sont décrites et peuvent être personnalisées.

Le modèle sur frameworks/av/services/audiopolicy/config/audio_policy_configuration.xml montre plusieurs de ces fonctionnalités en cours d'utilisation.

Format et emplacement du fichier

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

La structure de niveau supérieur contient des modules qui correspondent à chaque module matériel audio HAL, où chaque module a une liste de ports de mixage, de ports de périphérique et de routes :

  • Les ports de mixage décrivent les profils de configuration possibles pour les flux qui peuvent être ouverts sur la HAL audio pour la lecture et la capture.
  • Les ports de périphérique décrivent les périphériques pouvant être connectés avec leur type (et éventuellement l'adresse et les propriétés audio, le cas échéant).
  • Les routes sont séparées du descripteur de port mixte, permettant la description des routes d'un appareil à l'autre ou d'un flux à l'autre.

Les tables de volume sont de simples listes de points définissant la courbe utilisée pour passer d'un index UI à un 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 de périphérique donnés peut être écrasée.

Inclusions de fichiers

La méthode XML Inclusions (XInclude) peut être utilisée pour inclure des informations de configuration de politique 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 niveau supérieur.
  • Les fichiers ne peuvent pas contenir d'éléments XInclude.

Utilisez les inclusions pour éviter de copier les informations de configuration du module HAL audio standard d'Android Open Source Project (AOSP) dans tous les fichiers de configuration de la politique audio (ce qui est sujet aux erreurs). Un fichier XML de configuration de politique audio standard est fourni pour les HAL audio suivants :

  • A2DP : a2dp_audio_policy_configuration.xml
  • Rediriger le sous-mix : rsubmix_audio_policy_configuration.xml
  • USB : usb_audio_policy_configuration.xml

Organisation du code de politique audio

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

Module La description
/managerdefault Inclut les interfaces génériques et l'implémentation de comportement commune à toutes les applications. Semblable à AudioPolicyManager.cpp avec la fonctionnalité du moteur et les concepts communs abstraits.
/common Définit les classes de base (par exemple, les structures de données pour les profils de flux audio de sortie d'entrée, les descripteurs de périphérique audio, les correctifs audio et les ports audio). Cela a été précédemment défini dans AudioPolicyManager.cpp .
/engine

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

Disponible en deux versions : configurable et par défaut . Pour plus d'informations sur la sélection de la version, consultez Configuration à l'aide de Parameter Framework .

/engineconfigurable Implémentation du moteur de politique qui s'appuie sur Parameter Framework (voir ci-dessous). La configuration est basée sur le Parameter Framework et où la politique est définie par des fichiers XML.
/enginedefault Implémentation du moteur de politique basée sur les implémentations précédentes d'Android Audio Policy Manager. Il s'agit de la valeur par défaut et inclut des règles codées en dur qui correspondent aux implémentations Nexus et AOSP.
/service Inclut les interfaces de classeur, les threads et l'implémentation du verrouillage avec l'interface avec le reste du framework.

Configuration à l'aide de Parameter Framework

Le code de politique audio est organisé pour faciliter sa compréhension et sa maintenance tout en prenant en charge une politique audio entièrement définie par des fichiers de configuration. L'organisation et la conception de la politique audio sont basées sur le framework de paramètres d'Intel, un cadre basé sur des plugins et basé sur des règles pour la gestion des paramètres.

L'utilisation de la politique audio configurable permet aux fournisseurs OEM de :

  • Décrire la structure d'un système et ses paramètres en XML.
  • Écrivez (en C++) ou réutilisez un backend (plugin) pour accéder aux paramètres décrits.
  • Définir (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 politique audio qui utilise le framework de paramètres dans Frameworks/av/services/audiopolicy/engineconfigurable/parameter-framework/example/Settings/PolicyConfigurableDomains.xml . Pour plus de détails, reportez-vous à la documentation Intel sur Parameter Framework .

Dans Android 10 ou version antérieure, la stratégie audio configurable est sélectionnée à l'aide de l'option USE_CONFIGURABLE_AUDIO_POLICY . Sous Android 11 ou supérieur, la version du moteur de politique audio est sélectionnée dans le fichier audio_policy_configuration.xml . Pour sélectionner le moteur de politique 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 des règles audio

Android 6.0 a introduit une API publique d'énumération et de sélection qui se trouve au-dessus de l'infrastructure de patch audio/port audio et permet aux développeurs d'applications d'indiquer une préférence pour une sortie ou une entrée de périphérique spécifique pour les enregistrements ou pistes audio connectés.

Dans Android 7.0, l'API d'énumération et de sélection est vérifiée par des tests CTS et est é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 déprécie les méthodes de routage explicites qui étaient spécifiques aux classes AudioTrack et AudioRecord .

Pour plus de détails sur l'API d'énumération et de sélection, reportez-vous aux interfaces de configuration Android et OpenSLES_AndroidConfiguration.h . Pour plus de détails sur le routage audio, reportez-vous à AudioRouting .

Prise en charge multicanal

Si votre matériel et votre pilote prennent en charge l'audio multicanal via HDMI, vous pouvez émettre le flux audio directement sur le matériel audio (cela contourne le mélangeur AudioFlinger afin qu'il ne soit pas mixé sur deux canaux.) Le HAL audio doit indiquer si un profil de flux de sortie prend en charge les capacités audio multicanaux. Si HAL expose ses capacités, le gestionnaire de règles par défaut autorise la lecture multicanal via HDMI. Pour plus de détails sur la mise en œuvre, voir device/samsung/tuna/audio/audio_hw.c .

Pour spécifier que votre produit contient une sortie audio multicanal, modifiez le fichier de configuration de la politique audio pour décrire la sortie multicanal de votre produit. L'exemple suivant 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 politique audio interroge les masques de canal pris en charge par 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 mixe automatiquement le contenu en stéréo lorsqu'il est envoyé à un périphérique audio qui ne prend pas en charge l'audio multicanal.

Codecs multimédias

Assurez-vous que les codecs audio pris en charge par votre matériel et vos pilotes sont correctement déclarés pour votre produit. Pour plus de détails, consultez Exposer les codecs au framework .