Konfigurowanie zasad dotyczących dźwięku

W Androidzie 10 wprowadziliśmy znaczące zmiany w menedżerze zasad audio, aby zapewnić większą elastyczność w obsłudze złożonych przypadków użycia w motoryzacji:

  • Strategie routingu specyficzne dla producenta OEM.
  • Konfigurowalne grupy głośności dla grup starszych typów strumieni, które korzystają z tych samych krzywych głośności.
  • Strategie routingu są deklarowane przez silnik zasad audio, a nie zakodowane na stałe.
  • Krzywe głośności i grupy zarządzane przez silnik zasad audio.
  • Wewnętrzne refaktoryzacja przygotowująca do przyszłego podziału na kod wspólny i konfigurowalny oraz oferująca bogatsze zarządzanie 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 do deklarowania urządzeń audio obecnych w produkcie trzeba było używać pliku device/<company>/<device>/audio/audio_policy.conf (przykład tego pliku dla sprzętu audio Galaxy Nexus znajdziesz w device/samsung/tuna/audio/audio_policy.conf). Jednak CONF to prosty format zastrzeżony, który jest zbyt ograniczony, aby opisywać złożone topologie w przypadku takich branż jak telewizory i samochody.

Android 7.0 wycofał audio_policy.conf i dodał obsługę definiowania topologii audio za pomocą pliku XML, który jest bardziej czytelny, ma szeroki zakres 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 wyboru formatu XML plików konfiguracyjnych.

Zalety formatu XML

Podobnie jak w przypadku pliku CONF, plik XML umożliwia określenie liczby i rodzajów profili strumieni wyjściowych i wejściowych, urządzeń, które można wykorzystać do odtwarzania i nagrywania, oraz atrybutów audio. Format XML oferuje też te ulepszenia:

  • W Androidzie 10 można jednocześnie uruchomić więcej niż jedną aktywną aplikację do nagrywania.
    • Rozpoczęcie nagrywania nigdy nie jest odrzucane z powodu sytuacji związanej z jednoczesnym nagrywaniem.
    • Funkcja zwrotna registerAudioRecordingCallback(AudioManager.AudioRecordingCallback cb) powiadamia klientów o zmianach ścieżki przechwytywania.
  • W tych sytuacjach klient otrzymuje próbki dźwięku bez dźwięku:
    • aktywny jest przypadek użycia wymagający ochrony prywatności (np. VOICE_COMMUNICATION);
    • Klient nie ma usługi na pierwszym planie ani interfejsu na pierwszym planie.
    • Zasady rozpoznają role specjalne:
      • Usługa ułatwień dostępu: może nagrywać nawet wtedy, gdy aktywne jest zastosowanie wymagające ochrony prywatności.
      • Asystent: uznawany za wrażliwy pod względem prywatności, jeśli interfejs jest na wierzchu.
  • Profile audio mają strukturę podobną do prostych deskryptorów audio HDMI, co umożliwia stosowanie różnych zestawów częstotliwości próbkowania i masek kanałów dla każdego formatu audio.
  • Istnieją wyraźne definicje wszystkich możliwych połączeń między urządzeniami a strumieniami. Wcześniej reguła domyślna umożliwiała łączenie wszystkich urządzeń podłączonych do tego samego modułu HAL, co uniemożliwiało sterowanie połączeniami żądanymi za pomocą interfejsów API ścieżki audio. W formacie XML opis topologii określa ograniczenia połączeń.
  • Obsługa obejmuje unikanie powtarzania standardowych definicji A2DP, USB lub przekierowania przesyłania.
  • Krzywe głośności można dostosowywać. Wcześniej tabele wolumenu były zakodowane na stałe. W formacie XML opisane są tabele objętości, które można dostosowywać.

Szablon na stronieframeworks/av/services/audiopolicy/config/audio_policy_configuration.xml pokazuje wiele z tych funkcji w użyciu.

Format i lokalizacja pliku

Nowy plik konfiguracji zasad dotyczących dźwięku to audio_policy_configuration.xml i znajduje się w lokalizacji /system/etc. Poniższe przykłady pokazują prostą konfigurację zasad dotyczących dźwięku w formacie pliku XML w przypadku Androida 12 i wersji starszych.

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

  • Mix ports opisuje możliwe profile konfiguracji strumieni, które można otworzyć w warstwie HAL audio na potrzeby odtwarzania i nagrywania.
  • Device ports opisuje urządzenia, które można podłączyć, wraz z ich typem (opcjonalnie adresem i właściwościami audio, jeśli ma to znaczenie).
  • Trasy są oddzielone od deskryptora portu miksowania, co umożliwia opis tras z urządzenia na urządzenie lub ze strumienia na urządzenie.

Tabele głośności to proste listy punktów określających krzywą używaną do przeliczania indeksu interfejsu na głośność w dB. Osobny plik dołączany zawiera domyślne krzywe, ale każdą krzywą dla danego zastosowania i kategorii urządzenia można zastąpić.

Włączenie plików

Metoda XML Inclusions (XInclude) może służyć 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 uwzględnieniem tych ograniczeń:

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

Używaj instrukcji include, aby uniknąć kopiowania informacji o konfiguracji standardowego modułu HAL audio w Projekcie Android Open Source (AOSP) do wszystkich plików konfiguracji zasad audio (co jest podatne na błędy). Standardowy plik konfiguracji zasad audio XML jest dostępny w przypadku tych interfejsów HAL audio:

  • A2DP: a2dp_audio_policy_configuration.xml
  • Przekieruj submiksy: 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, co ułatwia jego utrzymanie i konfigurowanie. Organizacja frameworks/av/services/audiopolicy obejmuje te moduły:

Moduł Opis
/managerdefault Obejmuje ogólne interfejsy i implementację zachowań wspólne dla wszystkich aplikacji. Podobnie jak AudioPolicyManager.cpp z funkcjami silnika i ogólnymi pojęciami.
/common Definiuje klasy bazowe (np. struktury danych dla profili wejściowego i wyjściowego strumienia audio, deskryptory urządzeń audio, ścieżki audio i porty audio). Wcześniej była ona zdefiniowana w AudioPolicyManager.cpp.
/engine

Wdraża reguły określające, które urządzenie i woluminy powinny być używane w danym przypadku. Implementuje standardowy interfejs z częścią ogólną, np. w celu uzyskania odpowiedniego urządzenia do danego przypadku użycia odtwarzania lub przechwytywania albo ustawienia podłączonych urządzeń lub stanu zewnętrznego (np. stanu połączenia wymuszonego użycia), który może zmienić decyzję o routingu.

Dostępne w 2 wersjach: konfigurowalnej i domyślnej. Informacje o tym, jak wybrać wersję, znajdziesz w sekcji Konfigurowanie za pomocą platformy parametrów.
/engineconfigurable Implementacja silnika zasad oparta na platformie parametrów (patrz poniżej). Konfiguracja opiera się na strukturze parametrów, a zasady są definiowane przez pliki XML.
/enginedefault Implementacja silnika zasad oparta na poprzednich implementacjach Menedżera zasad audio na Androidzie. Jest to ustawienie domyślne, które obejmuje reguły zakodowane na stałe i odpowiadające implementacjom Nexus i AOSP.
/service Obejmuje interfejsy binder, wątki i implementację blokowania z interfejsem do reszty platformy.

Konfiguracja za pomocą platformy parametrów

Kod zasad dotyczących dźwięku jest zorganizowany w taki sposób, aby był łatwy do zrozumienia i utrzymania, a jednocześnie obsługiwał zasady dotyczące dźwięku zdefiniowane w całości przez pliki konfiguracyjne. Organizacja i projekt zasad dotyczących dźwięku opierają się na platformie parametrów firmy Intel, która jest opartą na wtyczkach i regułach platformą do obsługi parametrów.

Korzystanie z konfigurowalnych zasad dotyczących dźwięku umożliwia producentom OEM:

  • Opisz strukturę systemu i jego parametry w formacie XML.
  • Napisz (w C++) lub ponownie wykorzystaj backend (wtyczkę) do uzyskiwania dostępu do opisanych parametrów.
  • Zdefiniuj (w XML lub w języku specyficznym dla 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 platformy Parameter Framework w Frameworks/av/services/audiopolicy/engineconfigurable/parameter-framework/example/Settings/PolicyConfigurableDomains.xml. Szczegółowe informacje znajdziesz w dokumentacji firmy Intel na temat Parameter Framework.

W Androidzie 10 i starszych wersjach konfigurowalna strategia audio jest wybierana za pomocą opcji kompilacji USE_CONFIGURABLE_AUDIO_POLICY. W Androidzie 11 lub nowszym wersja silnika zasad audio jest wybierana w pliku audio_policy_configuration.xml. Aby wybrać konfigurowalny silnik zasad dotyczących dźwięku, ustaw wartość atrybutu engine_libraryelementu globalConfiguration na configurable, jak w tym przykładzie:

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

Interfejsy API routingu zasad dotyczących dźwięku

W Androidzie 6.0 wprowadzono publiczny interfejs API wyliczania i wyboru, który jest oparty na infrastrukturze ścieżki/portu audio i umożliwia programistom aplikacji określanie preferencji dotyczących konkretnego wyjścia lub wejścia urządzenia w przypadku podłączonych nagrań lub ścieżek audio.

W Androidzie 7.0 interfejs API wyliczania i wyboru jest weryfikowany przez testy CTS i rozszerzony o routing natywnych strumieni audio C/C++ (OpenSL ES). Kierowanie strumieni natywnych nadal odbywa się w języku Java. Dodaliśmy interfejs AudioRouting, który zastępuje, łączy i wycofuje metody kierowania jawnego, które były specyficzne dla klas AudioTrack i AudioRecord.

Szczegółowe informacje o interfejsie Enumeration and Selection API znajdziesz w sekcjach Interfejsy konfiguracji Androida i OpenSLES_AndroidConfiguration.h. Więcej informacji o przekierowywaniu 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 (pomija to mikser AudioFlinger, więc nie jest on miksowany do dwóch kanałów). Warstwa HAL audio musi udostępniać informacje o tym, czy profil strumienia wyjściowego obsługuje dźwięk wielokanałowy. 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 device/samsung/tuna/audio/audio_hw.c.

Aby określić, że produkt zawiera wielokanałowe wyjście audio, zmień plik konfiguracyjny zasad dotyczących dźwięku, aby opisać wielokanałowe wyjście produktu. Ten przykład z frameworks/av/services/audiopolicy/config/primary_audio_policy_configuration_tv.xml przedstawia dynamiczną maskę kanału, co oznacza, że po połączeniu menedżer zasad audio wysyła zapytanie do odbiornika HDMI o maski kanałów, które obsługuje.

Możesz też określić statyczną maskę kanału, np.AUDIO_CHANNEL_OUT_5POINT1. Mikser AudioFlingera automatycznie miksuje treści do stereo, gdy są one wysyłane do urządzenia 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 dla Twojego produktu. Więcej informacji znajdziesz w artykule Udostępnianie kodeków w ramach platformy.