Skonfiguruj zasady dotyczące dźwięku

Wersja Androida 10 obejmuje znaczną refaktoryzację menedżera zasad audio, aby zapewnić większą elastyczność w obsłudze złożonych przypadków zastosowań motoryzacyjnych:

  • Strategie routingu specyficzne dla OEM.
  • Konfigurowalne grupy woluminów dla grup starszych typów strumieni korzystających z tych samych krzywych głośności.
  • Strategie routingu zadeklarowane przez silnik zasad audio zamiast być zakodowane na stałe.
  • Krzywe głośności i grupy zarządzane przez silnik zasad audio.
  • Wewnętrzna refaktoryzacja przygotowująca do przyszłego podziału między wspólnym kodem a kodem konfigurowalnym i oferująca bogatsze zarządzanie urządzeniami audio. Na przykład użycie w regułach polityki wszystkich właściwości urządzenia, a nie tylko jego typu.

W systemie Android 7.0 wprowadzono format pliku konfiguracyjnego zasad audio (XML) do opisywania topologii audio.

Poprzednie wersje Androida wymagały użycia polecenia device/<company>/<device>/audio/audio_policy.conf w celu zadeklarowania urządzeń audio znajdujących się w Twoim produkcie (przykład tego pliku dla sprzętu audio Galaxy Nexus możesz zobaczyć w device/samsung/tuna/audio/audio_policy.conf ). Jednak CONF jest prostym, zastrzeżonym formatem, który jest zbyt ograniczony, aby opisywać złożone topologie dla branż takich jak telewizory i samochody.

W systemie Android 7.0 plik audio_policy.conf został wycofany i dodano obsługę definiowania topologii audio przy użyciu formatu pliku XML, który jest bardziej czytelny dla człowieka, zawiera szeroką gamę narzędzi do edycji i analizowania oraz jest wystarczająco elastyczny, aby opisywać złożone topologie audio. Android 7.0 używa flagi kompilacji USE_XML_AUDIO_POLICY_CONF do wybierania formatu XML plików konfiguracyjnych.

Zalety formatu XML

Podobnie jak w pliku CONF, plik XML umożliwia zdefiniowanie liczby i typów profili strumieni wyjściowych i wejściowych, urządzeń możliwych do odtwarzania i przechwytywania oraz atrybutów audio. Ponadto format XML oferuje następujące ulepszenia:

  • W systemie Android 10 dozwolona jest jednocześnie więcej niż jedna aktywna aplikacja do nagrywania.
    • Rozpoczęcie nagrywania nigdy nie jest odrzucane ze względu na sytuację współbieżności.
    • Wywołanie zwrotne registerAudioRecordingCallback(AudioManager.AudioRecordingCallback cb) powiadamia klientów o zmianach ścieżki przechwytywania.
  • W następujących sytuacjach klient otrzymuje ciche próbki audio:
    • Przypadek użycia wrażliwy na prywatność (na przykład VOICE_COMMUNICATION ) jest aktywny.
    • Klient nie ma usługi pierwszego planu ani interfejsu użytkownika pierwszego planu.
    • Role specjalne są uznawane przez politykę:
      • Usługa ułatwień dostępu: może nagrywać, nawet jeśli aktywny jest przypadek użycia wrażliwy na prywatność.
      • Asystent: Uważany za wrażliwy na prywatność, jeśli interfejs użytkownika jest na górze.
  • Profile audio mają strukturę podobną do prostych deskryptorów audio HDMI, umożliwiając inny zestaw częstotliwości próbkowania/masek kanałów dla każdego formatu audio.
  • Istnieją wyraźne definicje wszystkich możliwych połączeń między urządzeniami i strumieniami. Wcześniej niejawna reguła umożliwiała podłączenie wszystkich urządzeń podłączonych do tego samego modułu HAL, uniemożliwiając polityce audio kontrolowanie połączeń żądanych za pomocą interfejsów API poprawek audio. W formacie XML opis topologii określa ograniczenia połączeń.
  • Obsługa dołączeń pozwala uniknąć powtarzania standardowych definicji przesyłania A2DP, USB lub przekierowania.
  • Krzywe objętości można dostosować. Wcześniej tabele woluminów były zakodowane na stałe. W formacie XML tabele objętości są opisane i można je dostosować.

Szablon w frameworks/av/services/audiopolicy/config/audio_policy_configuration.xml pokazuje, że wiele z tych funkcji jest w użyciu.

Format i lokalizacja pliku

Nowy plik konfiguracyjny zasad audio to audio_policy_configuration.xml i znajduje się w /system/etc . Poniższe przykłady pokazują prostą konfigurację zasad audio w formacie pliku XML dla Androida 12 i wersji poniżej Androida 12.

Struktura najwyższego poziomu zawiera moduły odpowiadające każdemu modułowi sprzętowemu audio HAL, gdzie każdy moduł ma listę portów miksowania, portów urządzeń i tras:

  • Porty miksowania opisują możliwe profile konfiguracyjne dla strumieni, które można otworzyć w warstwie audio HAL w celu odtwarzania i przechwytywania.
  • Porty urządzeń opisują urządzenia, które można podłączyć, wraz z ich typem (oraz opcjonalnie adresem i właściwościami audio, jeśli ma to zastosowanie).
  • Trasy są oddzielone od deskryptora portu miksującego, umożliwiając opisanie tras od urządzenia do urządzenia lub strumienia do urządzenia.

Tabele głośności to proste listy punktów definiujące krzywą używaną do przeliczenia indeksu interfejsu użytkownika na głośność w dB. Oddzielny plik zawiera krzywe domyślne, ale każdą krzywą dla danego przypadku użycia i kategorii urządzenia można nadpisać.

Dołączenia plików

Metodę XML Inclusions (XInclude) można wykorzystać do dołączenia informacji o konfiguracji zasad audio znajdujących się w innych plikach XML. Wszystkie dołączone pliki muszą mieć strukturę opisaną powyżej z następującymi ograniczeniami:

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

Użyj, aby uniknąć kopiowania standardowych informacji o konfiguracjach modułu audio HAL systemu Android Open Source Project (AOSP) do wszystkich plików konfiguracyjnych zasad audio (co jest podatne na błędy). Dostępny jest standardowy plik XML konfiguracji zasad audio dla następujących warstw audio HAL:

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

Organizacja kodu zasad audio

AudioPolicyManager.cpp jest podzielony na kilka modułów, aby ułatwić jego konserwację i konfigurację. Organizacja frameworks/av/services/audiopolicy obejmuje następujące moduły.

Moduł Opis
/managerdefault Obejmuje ogólne interfejsy i implementację zachowań wspólne dla wszystkich aplikacji. Podobny do AudioPolicyManager.cpp z usuniętymi funkcjami silnika i typowymi koncepcjami.
/common Definiuje klasy podstawowe (na przykład struktury danych dla profili wejściowych i wyjściowych strumieni audio, deskryptory urządzeń audio, poprawki audio i porty audio). Zostało to wcześniej zdefiniowane w pliku AudioPolicyManager.cpp .
/engine

Implementuje reguły definiujące, które urządzenie i woluminy powinny zostać użyte w danym przypadku użycia. Implementuje standardowy interfejs z częścią ogólną, na przykład w celu uzyskania odpowiedniego urządzenia dla danego przypadku użycia odtwarzania lub przechwytywania lub ustawienia podłączonych urządzeń lub stanu zewnętrznego (tj. stanu wywołania wymuszonego użycia), który może zmienić routing decyzja.

Dostępny w dwóch wersjach: konfigurowalnej i domyślnej . Aby uzyskać informacje na temat wybierania wersji, zobacz Konfiguracja przy użyciu struktury parametrów .

/engineconfigurable Implementacja silnika zasad oparta na strukturze parametrów (patrz poniżej). Konfiguracja opiera się na strukturze parametrów, a zasady są definiowane za pomocą plików XML.
/enginedefault Implementacja silnika zasad oparta na poprzednich implementacjach Android Audio Policy Manager. Jest to ustawienie domyślne i zawiera zakodowane na stałe reguły odpowiadające implementacjom Nexusa i AOSP.
/service Obejmuje interfejsy spoiw, implementację wątków i blokowania z interfejsem do pozostałej części platformy.

Konfiguracja przy użyciu struktury parametrów

Kod zasad audio jest zorganizowany tak, aby był łatwy do zrozumienia i utrzymania, a jednocześnie obsługuje politykę audio zdefiniowaną całkowicie przez pliki konfiguracyjne. Organizacja i projekt zasad audio opierają się na platformie Parameter Framework firmy Intel, platformie opartej na wtyczkach i regułach do obsługi parametrów.

Korzystanie z konfigurowalnych zasad audio umożliwia producentom OEM:

  • Opisz strukturę systemu i jego parametry w formacie XML.
  • Napisz (w C++) lub ponownie użyj backendu (wtyczki) w celu uzyskania dostępu do opisanych parametrów.
  • Zdefiniuj (w języku XML lub w języku domeny) warunki/reguły, według których dany parametr musi przyjąć daną wartość.

AOSP zawiera przykład pliku konfiguracyjnego zasad audio, który korzysta ze struktury parametrów w Frameworks/av/services/audiopolicy/engineconfigurable/parameter-framework/example/Settings/PolicyConfigurableDomains.xml . Szczegółowe informacje można znaleźć w dokumentacji firmy Intel dotyczącej struktury parametrów .

W systemie Android 10 lub starszym konfigurowalne zasady audio są wybierane za pomocą opcji kompilacji USE_CONFIGURABLE_AUDIO_POLICY . W systemie Android 11 lub nowszym wersję silnika zasad audio wybiera się w pliku audio_policy_configuration.xml . Aby wybrać konfigurowalny silnik reguł audio, ustaw wartość atrybutu engine_library elementu globalConfiguration na configurable , jak w poniższym przykładzie:

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

Interfejsy API routingu zasad audio

W systemie Android 6.0 wprowadzono publiczny interfejs API wyliczania i wyboru, który znajduje się na infrastrukturze poprawki audio/portu audio i umożliwia twórcom aplikacji wskazanie preferencji dotyczących konkretnego wyjścia lub wejścia urządzenia dla podłączonych nagrań lub ścieżek audio.

W systemie Android 7.0 interfejs API wyliczania i wyboru jest weryfikowany za pomocą testów CTS i rozszerzany o routing dla natywnych strumieni audio C/C++ (OpenSL ES). Routing natywnych strumieni nadal odbywa się w języku Java z dodatkiem interfejsu AudioRouting , który zastępuje, łączy i wycofuje jawne metody routingu, które były specyficzne dla klas AudioTrack i AudioRecord .

Szczegółowe informacje na temat interfejsu API wyliczania i wyboru można znaleźć w interfejsach konfiguracyjnych systemu Android i OpenSLES_AndroidConfiguration.h . Aby uzyskać szczegółowe informacje na temat routingu audio, zobacz AudioRouting .

Obsługa wielu kanałów

Jeśli Twój sprzęt i sterownik obsługują dźwięk wielokanałowy przez HDMI, możesz wyprowadzić strumień audio bezpośrednio do sprzętu audio (pomija to mikser AudioFlinger, dzięki czemu nie jest on miksowany do dwóch kanałów). HAL audio musi ujawnić, czy profil strumienia wyjściowego obsługuje funkcje dźwięku wielokanałowego. Jeśli warstwa HAL ujawni swoje możliwości, domyślny menedżer zasad umożliwi odtwarzanie wielokanałowe przez HDMI. Szczegóły implementacji można znaleźć na stronie device/samsung/tuna/audio/audio_hw.c .

Aby określić, że produkt zawiera wielokanałowe wyjście audio, zmodyfikuj plik konfiguracyjny zasad audio, tak aby opisał wielokanałowe wyjście audio dla Twojego produktu. Poniższy przykład z frameworks/av/services/audiopolicy/config/primary_audio_policy_configuration_tv.xml przedstawia dynamiczną maskę kanału, co oznacza, że ​​menedżer zasad audio po połączeniu wysyła zapytanie do masek kanałów obsługiwanych przez ujście HDMI.

Można także określić statyczną maskę kanału, np. AUDIO_CHANNEL_OUT_5POINT1 . Mikser AudioFlingera automatycznie miksuje zawartość do stereo po wysłaniu do urządzenia audio, które nie obsługuje dźwięku wielokanałowego.

Kodeki multimedialne

Upewnij się, że kodeki audio obsługiwane przez Twój sprzęt i sterowniki są prawidłowo zadeklarowane dla Twojego produktu. Aby uzyskać szczegółowe informacje, zobacz Udostępnianie kodeków frameworkowi .