Audiorichtlinien konfigurieren

Die Android 10-Version umfasst eine erhebliche Refaktorierung der Audioinhalte. Policy Manager, um mehr Flexibilität für komplexe Anwendungsfälle in der Automobilbranche zu bieten:

  • OEM-spezifische Routingstrategien
  • Anpassbare Volumengruppen für Gruppen von Legacy-Streamtypen mit denselben Volumenkurven.
  • Routingstrategien, die von der Audiorichtlinien-Engine deklariert und nicht hartcodiert werden.
  • Von der Audiorichtlinien-Engine verwaltete Lautstärkekurven und Gruppen.
  • Internes Refactoring auf eine zukünftige Aufteilung zwischen gängigem Code und konfigurierbarem Code und eine umfassendere Verwaltung von Audiogeräten. Die Verwendung aller Geräteeigenschaften, nicht nur in die Richtlinienregeln ein.

Mit Android 7.0 wurde ein Dateiformat (XML) für die Konfiguration von Audiorichtlinien für die Ihre Audiotopologie beschreiben.

Für vorherige Android-Releases war Folgendes erforderlich: device/<company>/<device>/audio/audio_policy.conf um die auf Ihrem Produkt vorhandenen Audiogeräte anzugeben (Sie können sich ein Beispiel Datei für die Audio-Hardware des Galaxy Nexus in device/samsung/tuna/audio/audio_policy.conf). CONF ist jedoch einfaches, proprietäres Format, das zu beschränkt ist, um komplexe Topologien für wie Fernsehern und Autos.

Android 7.0 wurde eingestellt und unterstützt audio_policy.conf zum Definieren einer Audiotopologie mit einem XML-Dateiformat, menschenlesbar, bietet ein breites Spektrum an Bearbeitungs- und Parsing-Tools und ist flexibel, komplexe Audiotopologien zu beschreiben. Android 7.0 nutzt die Build-Flag USE_XML_AUDIO_POLICY_CONF zur Auswahl der XML-Datei Format von Konfigurationsdateien.

Vorteile des XML-Formats

Wie in der CONF-Datei können in der XML-Datei Anzahl und Typen definiert werden. von Ausgabe- und Eingabestreamprofilen, Geräten, die für Wiedergabe und Erfassung verwendet werden können, Audioattribute. Darüber hinaus bietet das XML-Format folgende Verbesserungen:

  • In Android 10 sind mehrere aktive Aufnahme-Apps gleichzeitig erlaubt.
    • Der Aufnahmestart wird aufgrund einer Gleichzeitigkeitslage nicht abgelehnt.
    • Das registerAudioRecordingCallback(AudioManager.AudioRecordingCallback cb) Callback informiert Clients über die Erfassung von Pfadänderungen.
  • In den folgenden Situationen erhält ein Client lautlose Audioinhalte: <ph type="x-smartling-placeholder">
      </ph>
    • Es ist ein datenschutzfreundlicher Anwendungsfall (z. B. VOICE_COMMUNICATION) aktiv.
    • Der Client hat keinen Dienst im Vordergrund und keine UI im Vordergrund.
    • Spezielle Rollen werden von der Richtlinie erkannt: <ph type="x-smartling-placeholder">
        </ph>
      • Bedienungshilfe: Kann auch dann aufzeichnen, wenn ein datenschutzfreundlicher Anwendungsfall aktiv ist.
      • Assistant: Wenn die Benutzeroberfläche oben ist, wird die Privatsphäre berücksichtigt.
  • Audioprofile haben eine ähnliche Struktur wie einfache HDMI-Audiodeskriptoren und ermöglichen eine andere Satz von Abtastraten/Kanalmasken für jedes Audioformat.
  • Es gibt explizite Definitionen für alle möglichen Verbindungen zwischen Geräten und Streams. Zuvor ermöglichte es eine implizite Regel, alle Geräte zu verbinden, die mit demselben HAL verbunden waren Modul, das verhindert, dass die Audiorichtlinie die per Audiopatch angeforderten Verbindungen steuert APIs Im XML-Format definiert die Topologiebeschreibung Verbindungseinschränkungen.
  • Unterstützung für include vermeidet wiederholte Übermittlung der standardmäßigen A2DP-, USB- oder Umleitungsübermittlungen. Definitionen.
  • Lautstärkekurven sind anpassbar. Bisher wurden Volumentabellen hartcodiert. In der XML-Datei Volume-Tabellen beschrieben und können angepasst werden.

Die Vorlage unter frameworks/av/services/audiopolicy/config/audio_policy_configuration.xml zeigt, dass viele dieser Funktionen genutzt werden.

Dateiformat und Speicherort

Die neue Konfigurationsdatei für die Audiorichtlinie ist audio_policy_configuration.xml und befindet sich in /system/etc. Die folgenden Beispiele zeigen eine einfache Konfiguration einer Audiorichtlinie in der XML-Dateiformat für Android 12 und die folgenden Versionen Android 12

Die Struktur der obersten Ebene enthält Module, die den einzelnen Audio-HALs entsprechen. Hardwaremodul, wobei jedes Modul eine Liste mit verschiedenen Ports, Geräteports und Routen:

  • Mixports beschreiben die möglichen Konfigurationsprofile für Streams das im Audio-HAL zur Wiedergabe und Aufnahme geöffnet werden kann.
  • Geräteports beschreiben die Geräte, die mit ihr Typ (und optional Adress- und Audioeigenschaften, falls relevant).
  • Routen ist vom Mix-Portdeskriptor getrennt. die Beschreibung von Routen von Gerät zu Gerät oder Stream zu Gerät aktiviert.

Volumentabellen sind einfache Listen von Punkten, die die für die Übersetzung verwendete Kurve definieren von einem UI-Index zu einem Lautstärkepegel in dB. Eine separate Include-Datei stellt Standard- aber jede Kurve für einen bestimmten Anwendungsfall und eine bestimmte Gerätekategorie überschrieben.

Eingeschlossene Dateien

Die Methode „XML Inclusion“ (XInclude) kann verwendet werden, um eine Audiorichtlinie einzuschließen Konfigurationsinformationen, die sich in anderen XML-Dateien befinden. Alle enthaltenen Dateien müssen befolgen Sie die oben beschriebene Struktur mit den folgenden Einschränkungen:

  • Dateien dürfen nur Elemente der obersten Ebene enthalten.
  • Dateien dürfen keine XInclude-Elemente enthalten.

Mit einzuschließen, um das Kopieren des standardmäßigen Android Open Source Project (AOSP) zu vermeiden Informationen zu Audio-HAL-Modulkonfigurationen für die gesamte Audiorichtlinienkonfiguration Dateien, die fehleranfällig sind. Eine Standard-XML-Konfigurationsdatei für Audiorichtlinien wird für die folgenden Audio-HALs bereitgestellt:

  • A2DP:a2dp_audio_policy_configuration.xml
  • Submix umleiten: rsubmix_audio_policy_configuration.xml
  • USB:usb_audio_policy_configuration.xml

Organisation von Audiorichtliniencode

AudioPolicyManager.cpp ist in mehrere Module aufgeteilt um die Wartung und Konfiguration zu vereinfachen. Die Organisation von frameworks/av/services/audiopolicy enthält Folgendes: folgenden Modulen.

Modul Beschreibung
/managerdefault Umfasst die allgemeinen allgemeinen Schnittstellen und Verhaltensimplementierungen. Apps. Ähnlich wie AudioPolicyManager.cpp mit Suchmaschine Funktionen und gängige Konzepte abstrahiert.
/common Definiert Basisklassen (z. B. Datenstrukturen für den Audiostream der Eingangsausgabe) Profile, Audiogerätedeskriptoren, Audio-Patches und Audioports). Dies war zuvor definiert in AudioPolicyManager.cpp.
/engine

Implementiert die Regeln, die definieren, welches Gerät und welche Volumes verwendet werden sollen für einen bestimmten Anwendungsfall. Es implementiert eine Standardschnittstelle mit dem generischen Teil, z. B. um das passende Gerät für einen bestimmten Anwendungsfall zu finden, Verbundene Geräte oder einen externen Status (d. h. einen Anrufstatus mit erzwungener Nutzung) festlegen, die Routingentscheidung ändern kann.

Verfügbar in zwei Versionen: konfigurierbar und Standard. Informationen zur Auswahl der Version finden Sie unter Konfiguration mit Parameter Framework.

/engineconfigurable Implementierung der Richtlinien-Engine, die auf dem Parameter Framework basiert (siehe unten). Die Konfiguration basiert auf dem Parameter Framework und dem Ort, an dem sich die Richtlinie befindet definiert durch XML-Dateien.
/enginedefault Richtlinien-Engine-Implementierung basierend auf dem vorherigen Android Audio Policy Manager Implementierungen. Dies ist die Standardeinstellung. Sie umfasst hartcodierte Regeln, entsprechen den Nexus- und AOSP-Implementierungen.
/service Umfasst binder-Schnittstellen, Threading und Locking-Implementierung mit der Schnittstelle zum restlichen Framework.

Konfiguration mit Parameter Framework

Der Code für Audiorichtlinien ist so strukturiert, und gleichzeitig eine Audiorichtlinie unterstützen, die vollständig durch die Konfiguration Dateien. Das Design der Organisations- und Audiorichtlinie basiert auf dem Parameter von Intel Framework, ein Plug-in- und regelbasiertes Framework zur Verarbeitung von Parametern.

Mit der konfigurierbaren Audiorichtlinie können Anbieter und OEMs Folgendes tun:

  • Beschreiben Sie die Struktur eines Systems und seine Parameter in XML.
  • Schreiben (in C++) oder Wiederverwendung eines Backends (Plug-in) für den beschriebenen Zugriff Parameter.
  • Definieren Sie Bedingungen/Regeln (in XML oder in einer domainspezifischen Sprache), für die muss ein bestimmter Parameter einen bestimmten Wert annehmen.

AOSP enthält ein Beispiel für eine Konfigurationsdatei für Audiorichtlinien, die den Parameter Framework bei Frameworks/av/services/audiopolicy/engineconfigurable/parameter-framework/example/Settings/PolicyConfigurableDomains.xml. Für finden Sie in der Intel-Dokumentation Parameter-Framework:

In Android 10 oder niedriger ist die konfigurierbare Audiorichtlinie wird mit der Build-Option USE_CONFIGURABLE_AUDIO_POLICY ausgewählt. Ab Android 11 ist die Version der Audiorichtlinie Suchmaschine in der Datei audio_policy_configuration.xml ausgewählt ist. Legen Sie den Wert von engine_library fest, um das konfigurierbare Audiorichtlinienmodul auszuwählen Attribut des globalConfiguration-Elements auf configurable wie im folgenden Beispiel:

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

APIs für das Routing von Audiorichtlinien

Mit Android 6.0 wurde eine öffentliche Enumeration and Selection API eingeführt, die auf in die Audio-Patch-/Audio-Port-Infrastruktur ein und ermöglicht Entwickelnden eine Präferenz für die Ausgabe oder Eingabe eines bestimmten Geräts für verbundenen Audioaufzeichnungen oder Spuren.

In Android 7.0 wird die Enumeration and Selection API durch CTS-Tests geprüft und erweitert um das Routing für native C/C++-Audiostreams (OpenSL ES). Das Routing nativer Streams erfolgt weiterhin in Java. eine AudioRouting-Schnittstelle, die die Funktionen expliziten Routingmethoden, die für AudioTrack und AudioRecord Klassen.

Details zur Enumeration and Selection API finden Sie unter Android Konfigurationsoberflächen und OpenSLES_AndroidConfiguration.h. Weitere Informationen zum Audiorouting finden Sie unter AudioRouting

Support über mehrere Kanäle

Wenn Ihre Hardware und Ihr Treiber Mehrkanal-Audio über HDMI unterstützen, können Sie gibt den Audiostream direkt an die Audiohardware aus. Dadurch wird der AudioFlinger-Mischpult verwenden, damit es nicht auf zwei Kanäle heruntergemischt wird.) Der Audio-HAL muss angeben, ob ein Ausgabestreamprofil Mehrkanal-Audio unterstützt Funktionen. Wenn der HAL seine Funktionen bereitstellt, wird der Standard-Richtlinienmanager ermöglicht die Wiedergabe in mehreren Kanälen über HDMI. Implementierungsdetails: device/samsung/tuna/audio/audio_hw.c

Um anzugeben, dass Ihr Produkt eine Audioausgabe mit mehreren Kanälen bietet, bearbeiten Sie die Konfigurationsdatei für die Audiorichtlinie zur Beschreibung der Multi-Channel-Ausgabe für Ihr Produkt. Das folgende Beispiel aus frameworks/av/services/audiopolicy/config/primary_audio_policy_configuration_tv.xml zeigt eine dynamische Kanalmaske an, was bedeutet, dass der Audiorichtlinien-Manager den Kanal abfragt. Masken, die nach der Verbindung von der HDMI-Senke unterstützt werden.

Sie können auch eine statische Kanalmaske wie AUDIO_CHANNEL_OUT_5POINT1 Mit dem Mischpult von AudioFlinger automatisch auf Stereo auf Stereo, wenn sie an ein Audiogerät gesendet werden, unterstützen Multi-Channel-Audio.

Medien-Codecs

Prüfen Sie, ob die Audio-Codecs, die Ihre Hardware und Ihre Treiber unterstützen, richtig sind für Ihr Produkt deklariert. Weitere Informationen finden Sie unter Codecs für den Framework.