Konfigurowanie zasad dotyczących dźwięku

Wersja Androida 10 zawiera znaczącą refaktoryzację menedżera zasad dotyczących dźwięku, aby zapewnić większą elastyczność w obsługiwaniu złożonych zastosowań motoryzacyjnych:

  • Strategie routingu dla poszczególnych producentów OEM.
  • Grupy głośności, które można dostosowywać, dla grup starszych typów strumieni za pomocą tych samych krzywych głośności.
  • strategie routingu deklarowane przez mechanizm zasad audio zamiast być zakodowane na stałe.
  • Krzywe głośności i grupy zarządzane przez mechanizm zasad dotyczących dźwięku.
  • Wewnętrzny refaktoring w ramach przygotowań do przyszłego podziału na kod wspólny i kod konfigurowalny oraz zapewnienie bogatszego zarządzania urządzeniami audio. Na przykład w regułach zasad można używać wszystkich właściwości urządzenia, a nie tylko jego typu.

W Androidzie 7.0 wprowadzono format pliku konfiguracji zasad audio (XML) do opisywania topologii audio.

W poprzednich wersjach Androida wymagane było używanie pliku device/<company>/<device>/audio/audio_policy.conf do deklarowania urządzeń audio obecnych w produkcie (przykład tego pliku dla sprzętu audio Galaxy Nexus znajdziesz w pliku device/samsung/tuna/audio/audio_policy.conf). Jednak plik CONF to prosty, zastrzeżony format, który jest zbyt ograniczony, aby opisywać złożone topologie w branżach takich jak telewizory czy samochody.

wycofane w Androidzie 7.0 audio_policy.conf i dodano obsługę definiowania topologii audio za pomocą formatu pliku XML, który jest bardziej czytelny dla człowieka, zawiera szeroki zakres narzędzi do edycji i analizy oraz jest na tyle elastyczny, że umożliwia opisywanie złożonych topologii audio. Android 7.0 używa parametru kompilacji USE_XML_AUDIO_POLICY_CONF do wyboru formatu XML plików konfiguracji.

Zalety formatu XML

Podobnie jak plik CONF, plik XML umożliwia definiowanie liczby i typów profili strumienia wyjściowego i wejściowego, urządzeń do odtwarzania i rejestrowania oraz atrybutów audio. Format XML zapewnia też te ulepszenia:

  • W Androidzie 10 można jednocześnie używać więcej niż 1 aktywnej aplikacji do nagrywania.
    • Rozpoczęcie nagrywania nigdy nie jest odrzucane z powodu sytuacji równoległej.
    • registerAudioRecordingCallback(AudioManager.AudioRecordingCallback cb) callback powiadamia klientów o zmianach ścieżki przechwytywania.
  • W tych sytuacjach klient otrzymuje cichutkie próbki dźwiękowe:
    • Aktywny jest przypadek użycia, który wymaga ochrony prywatności (np. VOICE_COMMUNICATION).
    • Klient nie ma usługi na pierwszym planie ani interfejsu użytkownika na pierwszym planie.
    • Zasady uwzględniają te role specjalne:
      • Usługa ułatwień dostępu: może nagrywać nawet wtedy, gdy aktywne jest zastosowanie związane z ochrona prywatności.
      • Asystent: uważany za wrażliwy na prywatność, jeśli interfejs jest na górze.
  • Profile audio mają strukturę podobną do prostych opisów dźwięku HDMI, co umożliwia stosowanie innego zestawu częstotliwości próbkowania lub masek kanałów w przypadku każdego formatu audio.
  • Istnieją wyraźne definicje wszystkich możliwych połączeń między urządzeniami i strumieniami. Wcześniej reguła domyślna umożliwiała łączenie wszystkich urządzeń podłączonych do tego samego modułu HAL, uniemożliwiając zasadom dotyczącym dźwięku kontrolowanie połączeń żądanych za pomocą interfejsów API z patchem audio. W formacie XML opis topologii określa ograniczenia połączenia.
  • Obsługa includes pozwala uniknąć powtarzania standardowych definicji A2DP, USB i przekierowania przesyłania.
  • Krzywe głośności można dostosowywać. Wcześniej tabele objętości były zakodowane na stałe. W formacie XML tabele objętości są opisane i można je dostosować.

Szablon dostępny pod adresemframeworks/av/services/audiopolicy/config/audio_policy_configuration.xmlpokazuje wiele z tych funkcji w akcji.

Format i lokalizacja pliku

Nowy plik konfiguracji zasad dotyczących dźwięku toaudio_policy_configuration.xml, który znajduje się w folderze/system/etc. Poniższe przykłady pokazują prostą konfigurację zasad dotyczących dźwięku w formacie pliku XML na potrzeby Androida 12 i wersji starszych niż Android 12.

Struktura najwyższego poziomu zawiera moduły odpowiadające poszczególnym modułom sprzętowym HAL audio, a każdy z nich ma listę portów miksowania, portów urządzeń i tras:

  • Porty miksowania opisują możliwe profile konfiguracji strumieni, które można otworzyć w HAL dźwięku na potrzeby odtwarzania i przechwytywania.
  • Porty urządzenia opisują urządzenia, które można podłączyć, wraz z ich typem (i opcjonalnie właściwościami adresu i dźwięku, jeśli są dostępne).
  • Routes jest oddzielone od deskryptora portu mix, co umożliwia opisywanie tras z urządzenia na urządzenie lub z strumienia na urządzenie.

Tabele głośności to proste listy punktów definiujących krzywą służącą do przekształcania indeksu interfejsu w głośność w dB. Oddzielny plik include zawiera domyślne krzywe, ale każdą krzywą dla danego zastosowania i kategorii urządzenia można zastąpić.

Włączanie plików

Metody uwzględniania kodu XML (XInclude) można używać do uwzględniania informacji o konfiguracji zasad dotyczących dźwięku znajdujących się w innych plikach XML. Wszystkie uwzględnione pliki muszą mieć strukturę opisaną powyżej z tymi ograniczeniami:

  • Pliki mogą zawierać tylko elementy najwyższego poziomu.
  • Pliki nie mogą zawierać elementów XInclude.

Używaj poleceń, aby uniknąć kopiowania informacji o standardowych konfiguracjach modułu HAL dźwięku z projektu Android Open Source (AOSP) do wszystkich plików konfiguracji zasad dźwięku (co może powodować błędy). Standardowy plik XML konfiguracji zasad audio jest dostępny dla tych interfejsów HAL dźwięku:

  • A2DP: a2dp_audio_policy_configuration.xml
  • Przekieruj podmiks: rsubmix_audio_policy_configuration.xml
  • USB: usb_audio_policy_configuration.xml

Organizacja kodu zasad dotyczących dźwięku

AudioPolicyManager.cpp jest podzielony na kilka modułów, aby ułatwić jego konfigurowanie i obsługę. Organizacja frameworks/av/services/audiopolicy obejmuje te moduły:

Moduł Opis
/managerdefault Obejmuje interfejsy i zachowanie wspólne dla wszystkich aplikacji. Podobnie jak w przypadku AudioPolicyManager.cpp, funkcje silnika i pojęcia ogólne są abstrakcyjne.
/common Definiuje klasy podstawowe (np. struktury danych dla profili wejściowych profili strumienia audio, deskryptorów urządzeń audio, poprawek audio i portów audio). Wcześniej była ona zdefiniowana w AudioPolicyManager.cpp.
/engine

Wdraża reguły, które określają, które urządzenia i woluminy należy używać w danym przypadku użycia. Implementuje standardowy interfejs z częścią ogólną, aby uzyskać odpowiednie urządzenie do danego przypadku użycia odtwarzania lub rejestrowania albo ustawić połączone urządzenia lub stan zewnętrzny (czyli stan połączenia z wymuszonym użyciem), który może zmienić decyzję o przekierowaniu.

Dostępne w 2 wersjach: konfigurowalnejdomyślnej. Informacje o tym, jak wybrać wersję, znajdziesz w artykule Konfigurowanie za pomocą ramki parametrów.

/engineconfigurable Implementacja mechanizmu zasad, która opiera się na ramach parametrów (patrz poniżej). Konfiguracja opiera się na ramach parametrów i zasadach zdefiniowanych w plikach XML.
/enginedefault Wdrożenie mechanizmu zasad oparte na wcześniejszych implementacjach Menedżera zasad dotyczących dźwięku w Androidzie. Jest to domyślna opcja, która zawiera zakodowane na stałe reguły odpowiadające implementacjom w Nexusie i AOSP.
/service Obejmuje interfejsy bindera, implementację wątków i blokowania z interfejsem do reszty frameworka.

Konfiguracja za pomocą platformy parametrów

Kod zasad dotyczących dźwięku jest uporządkowany w sposób ułatwiający jego zrozumienie i utrzymanie, a jednocześnie obsługuje zasady dźwięku zdefiniowane wyłącznie przez pliki konfiguracji. Organizacja i projekt zasad dotyczących dźwięku są oparte na platformie Intel Parameter Framework, która jest platformą opartą na wtyczkach i regułach do obsługi parametrów.

Dzięki konfigurowalnej polityce dotyczącej dźwięku producenci OEM mogą:

  • Opisz strukturę systemu i jego parametry w formacie XML.
  • Aby uzyskać dostęp do opisanych parametrów, napisz (w C++) lub ponownie użyj backendu (wtyczki).
  • Zdefiniuj (w formacie XML lub w języku domeny) warunki lub reguły, na podstawie których dany parametr musi przyjmować określoną wartość.

AOSP zawiera przykładowy plik konfiguracji zasad audio, który korzysta z ramy parametrycznej (Frameworks/av/services/audiopolicy/engineconfigurable/parameter-framework/example/Settings/PolicyConfigurableDomains.xml). Szczegółowe informacje znajdziesz w dokumentacji firmy Intel na temat ramy danych.

W Androidzie 10 lub starszym konfigurowalną politykę dźwięku można wybrać za pomocą opcji kompilacji USE_CONFIGURABLE_AUDIO_POLICY. W Androidzie 11 lub nowszym wersja silnika zasad dotyczących dźwięku jest wybierana w pliku audio_policy_configuration.xml. Aby wybrać konfigurowalną wyszukiwarkę zasad dotyczących dźwięku, ustaw wartość atrybutu engine_library elementu globalConfiguration na configurable, jak w tym przykładzie:

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

Interfejsy API do kierowania dźwięku

Android 6.0 wprowadził publiczny interfejs API Enumeration and Selection, który działa na podstawie infrastruktury łatki audio lub portu audio i umożliwia deweloperom aplikacji wskazanie preferowanego wyjścia lub wejścia na urządzeniu dla połączonych nagrań lub ścieżek audio.

W Androidzie 7.0 interfejs API do zliczania i wyboru jest weryfikowany przez testy CTS i rozszerzony o przekierowywanie natywnych strumieni audio C/C++ (OpenSL ES). Przekierowywanie strumieni natywnych nadal odbywa się w języku Java, ale z dodatkiem interfejsu AudioRouting, który zastępuje, łączy i wycofa jawne metody kierowania, które były specyficzne dla klas AudioTrackAudioRecord.

Szczegółowe informacje o interfejsach konfiguracji interfejsu API Enumeration and Selection znajdziesz w interfejsach konfiguracji AndroidaOpenSLES_AndroidConfiguration.h. Szczegółowe informacje o przesyłaniu dźwięku znajdziesz w artykule AudioRouting.

Pomoc w wielu kanałach

Jeśli sprzęt i sterownik obsługują dźwięk wielokanałowy przez HDMI, możesz przesyłać strumień audio bezpośrednio do sprzętu audio (omijając mikser AudioFlinger, dzięki czemu nie zostanie on zmiksowany do 2 kanałów). HAL dźwięku musi udostępniać informacje o tym, czy profil strumienia wyjściowego obsługuje funkcje dźwięku wielokanałowego. Jeśli HAL udostępnia swoje możliwości, domyślny menedżer zasad zezwala na odtwarzanie wielokanałowe przez HDMI. Szczegóły wdrażania znajdziesz w dokumentacji device/samsung/tuna/audio/audio_hw.c.

Aby określić, że Twój produkt zawiera wyjście audio wielokanałowe, zmodyfikuj plik konfiguracji zasad dotyczących dźwięku, aby opisać wyjście wielokanałowe dla produktu. Poniższy przykład z frameworks/av/services/audiopolicy/config/primary_audio_policy_configuration_tv.xml pokazuje dynamiczną maskę kanału, co oznacza, że menedżer zasad dotyczących dźwięku wysyła zapytanie o maski kanałów obsługiwane przez odbiornik HDMI po połączeniu.

Możesz też podać stałą maskę kanału, np. AUDIO_CHANNEL_OUT_5POINT1. Mikser w AudioFlinger automatycznie konwertuje treści na dźwięk stereo, gdy zostaną wysłane na urządzenie audio, które nie obsługuje dźwięku wielokanałowego.

Kodeki multimediów

Upewnij się, że kodeki audio obsługiwane przez sprzęt i sterowniki są prawidłowo zadeklarowane w Twoim produkcie. Szczegółowe informacje znajdziesz w artykule Wyświetlanie kodeków w ramach frameworku.