Konfigurowanie zasad dotyczących audio

Wersja na Androida 10 obejmuje znaczną refaktoryzację dźwięku. menedżer zasad, który zapewnia większą elastyczność w obsłudze złożonych przypadków użycia w branży motoryzacyjnej:

  • Strategie routingu właściwe dla OEM.
  • Dostosowywane grupy woluminów dla grup starszych typów strumieni, które korzystają z tych samych krzywych ilości.
  • Strategie routingu zadeklarowane przez mechanizm zasad dotyczących dźwięku zamiast zakodowane na stałe.
  • Krzywe głośności i grupy zarządzane przez silnik zasad dotyczących dźwięku.
  • Wewnętrzne refaktoryzowanie przygotowujące do przyszłego podziału między kod wspólny i konfigurowalny i oferują pełniejsze funkcje zarządzania urządzeniami audio. Na przykład: wykorzystanie wszystkich właściwości urządzenia nie tylko i typu w regułach zasad.

W Androidzie 7.0 wprowadzono format pliku konfiguracji zasad audio (XML) na temat topologii audio.

Poprzednie wersje Androida wymagane przy użyciu device/<company>/<device>/audio/audio_policy.conf zadeklarowania, jakie urządzenia audio są zainstalowane w Twoim produkcie (możesz zobaczyć przykład dla sprzętu audio Galaxy Nexus device/samsung/tuna/audio/audio_policy.conf). CONF to jednak prosty, zastrzeżony format, który jest zbyt ograniczony, aby opisać złożone topologie takich jak telewizory i samochody.

Android 7.0 wycofał interfejs audio_policy.conf i dodano obsługę do definiowania topologii audio za pomocą plików w formacie XML, jest zrozumiały dla człowieka, ma szeroki wybór narzędzi do edycji i analizy oraz jest elastyczny do opisania złożonych topologii audio. Android 7.0 korzysta z Flaga kompilacji USE_XML_AUDIO_POLICY_CONF do wyboru kodu XML i formatu plików konfiguracyjnych.

Zalety formatu XML

Podobnie jak w przypadku pliku CONF, plik XML umożliwia zdefiniowanie liczby i typów profili strumieni wyjściowych i wejściowych, urządzeń używanych do odtwarzania i przechwytywania oraz atrybutów audio. Dodatkowo format XML udostępnia te ulepszenia:

  • Na Androidzie 10 więcej niż jedna aktywna aplikacja do nagrywania dozwolone jednocześnie.
    • Rozpoczęcie nagrywania nigdy nie jest odrzucane z powodu równoczesności.
    • registerAudioRecordingCallback(AudioManager.AudioRecordingCallback cb) wywołanie zwrotne powiadamia klientów o zmianach w ścieżce przechwytywania.
  • W tych sytuacjach klient otrzymuje ciche próbki dźwięku:
    • Uwzględnione jest przypadki użycia z uwzględnieniem ochrony prywatności (np. VOICE_COMMUNICATION).
    • Klient nie ma usługi na pierwszym planie ani interfejsu użytkownika na pierwszym planie.
    • Role specjalne są rozpoznawane przez te zasady:
      • Usługa ułatwień dostępu: umożliwia nagrywanie nawet wtedy, gdy aktywny jest przypadek użycia związany z ochroną prywatności.
      • Asystent: uznawany za poważną ochronę prywatności, jeśli interfejs jest umieszczony na samej górze.
  • Profile audio mają strukturę podobną do prostych deskryptorów dźwięku HDMI, umożliwiając zestaw częstotliwości próbkowania/maski kanału dla każdego formatu audio.
  • Istnieją konkretne definicje wszystkich możliwych połączeń między urządzeniami i strumieniami. Wcześniej reguła niejawna umożliwiała łączenie wszystkich urządzeń podłączonych do tej samej listy HAL. , który zapobiega kontrolowaniu przez zasadę audio połączeń żądanych za pomocą poprawki audio. API. W formacie XML opis topologii definiuje ograniczenia połączeń.
  • Obsługa uwzględniania uwzględnia pozwala uniknąć powtarzania przesyłania przez A2DP, USB i przekierowania ruchu. definicji.
  • Krzywe objętości można dostosowywać. Wcześniej tabele woluminów były zakodowane na stałe. W pliku XML i można je dostosować.

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

Format i lokalizacja pliku

Nowy plik konfiguracji zasad audio to audio_policy_configuration.xml i znajduje się w /system/etc Poniższe przykłady pokazują prostą konfigurację zasad audio w Format pliku XML na potrzeby Androida 12 i poniższych wersji Android 12.

Struktura najwyższego poziomu zawiera moduły odpowiadające każdemu z poszczególnych grup HAL audio. gdzie każdy moduł ma listę portów miksu, portów urządzenia trasy:

  • Porty miksu opisują możliwe profile konfiguracji strumieni. który można otworzyć na HAL audio w celu odtwarzania i przechwytywania.
  • Porty urządzeń opisują urządzenia, do których można podłączyć ich typ (i opcjonalnie adres i właściwości audio, jeśli są potrzebne).
  • Trasy są oddzielone od deskryptora portów mieszanych. w celu włączenia opisu tras z urządzenia na urządzenie lub przesyłania strumieniowego na urządzenie.

Tabele objętości to proste listy punktów definiujących krzywą używaną do tłumaczenia z indeksu interfejsu na wolumin w dB. Oddzielny plik dołączany domyślnie zapewnia ale każda krzywa dla danego przypadku użycia i kategorii urządzenia może być nadpisana.

Uwzględnienia plików

Metoda XML Inclusions (XInclude) może być używana do dodawania zasad audio. oraz informacje o konfiguracji znajdziesz w innych plikach XML. Wszystkie dołączone pliki muszą zachować zgodność ze strukturą opisaną powyżej z następującymi ograniczeniami:

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

Aby uniknąć kopiowania standardowego projektu Android Open Source Project (AOSP), użyj komponentu „includes”. informacje o konfiguracjach modułu HAL audio na całą konfigurację zasad audio. (które są podatne na błędy). Standardowy plik XML konfiguracji zasad audio jest obsługiwany w przypadku tych katalogów HAL audio:

  • A2DP: a2dp_audio_policy_configuration.xml
  • Przekieruj submiksję: rsubmix_audio_policy_configuration.xml
  • USB: usb_audio_policy_configuration.xml

Organizacja kodu zasad audio

Moduł AudioPolicyManager.cpp jest podzielony na kilka modułów co ułatwia obsługę i konfigurowanie. Organizacja frameworks/av/services/audiopolicy obejmuje kolejnych modułów.

Moduł Opis
/managerdefault Zawiera ogólne interfejsy i implementacje wspólne dla wszystkich aplikacji. Podobne do AudioPolicyManager.cpp z wyszukiwarką i ogólną funkcjonalność oraz koncepcje.
/common Definiuje klasy podstawowe (np. struktury danych wejściowego wyjściowego strumienia audio profile, deskryptory urządzeń audio, poprawki audio i porty audio). Wcześniej zdefiniowaną w komórce AudioPolicyManager.cpp.
/engine

Stosuje reguły określające, które urządzenia i głośności mają być używane dla danego przypadku użycia. implementuje standardowy interfejs z częścią ogólną, z jakiego urządzenia będą odpowiednie do danego przypadku użycia do odtwarzania lub nagrywania. ustawiają połączone urządzenia lub stan zewnętrzny (tzn. stan wywołania wymuszonego użycia), może zmienić decyzję o routingu.

Dostępne w 2 wersjach: configurable i default. Informacje na temat wyboru wersji znajdziesz w sekcji Konfigurowanie za pomocą platformy parametrów.

/engineconfigurable Implementacja silnika zasad oparta na platformie parametrów (patrz poniżej). Konfiguracja jest oparta na platformie parametrów i miejscu, w którym znajduje się zasada zdefiniowane w plikach XML.
/enginedefault Implementacja zasad opartych na poprzednim Menedżerze zasad dotyczących dźwięku na urządzeniach z Androidem implementacji. Jest to domyślne ustawienie i zawiera zakodowane na stałe reguły, które odpowiada implementacji Nexusu i AOSP.
/service Obejmuje interfejsy powiązań, wątki i blokowanie, i innych elementów platformy.

Konfigurowanie za pomocą platformy parametrów

Kod zasad dotyczących reklam audio został uporządkowany w taki sposób, aby był zrozumiały utrzymywania, jednocześnie obsługując zasadę audio zdefiniowaną całkowicie przez konfigurację . Konstrukcja zasad organizacji i zasad audio opiera się na parametrach firmy Intel Framework, czyli oparta na wtyczkach platforma do obsługi parametrów.

Dzięki konfigurowalnym zasadom dotyczącym dźwięku dostawcy OEM mogą:

  • Opisz strukturę systemu i jego parametry w pliku XML.
  • Możesz napisać (w C++) lub użyć backendu (wtyczki) do uzyskania dostępu .
  • Zdefiniuj (za pomocą pliku XML lub języka właściwego dla domeny) warunki/reguły, na których podstawie dany parametr musi mieć podaną wartość.

AOSP zawiera przykład pliku konfiguracji zasad audio, w którym jest używany parametr Platforma na stronie Frameworks/av/services/audiopolicy/engineconfigurable/parameter-framework/example/Settings/PolicyConfigurableDomains.xml. Dla: Więcej informacji znajdziesz w dokumentacji firmy Intel Platforma parametrów.

W Androidzie 10 i starszych wersjach zasady dotyczące dźwięku z możliwością konfiguracji jest wybierany za pomocą opcji kompilacji USE_CONFIGURABLE_AUDIO_POLICY. W Androidzie 11 lub nowszym wersja zasady dotyczącej dźwięku w pliku audio_policy_configuration.xml jest wybrana wyszukiwarka. Aby wybrać konfigurowalny mechanizm zasad dotyczących dźwięku, ustaw wartość engine_library atrybutu elementu globalConfiguration na configurable Jak w tym przykładzie:

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

Interfejsy API routingu zasad audio

W Androidzie 6.0 wprowadzono publiczny interfejs Enumeration and Selection API, poprawki na infrastrukturze audio/portu audio i zezwala programistów, aby określić preferencję dla danych wyjściowych lub wejściowych urządzenia przez połączone nagrania lub ścieżki audio.

W Androidzie 7.0 interfejs Enumeration and Selection API jest weryfikowany przez testy CTS. Rozszerzyliśmy też na routing na potrzeby natywnych strumieni audio w języku C/C++ (OpenSL ES). Routing natywnych strumieni jest nadal wykonywany w Javie, a dodatkowo dodano interfejs AudioRouting, który zastępuje, łączy i wycofuje funkcje konkretne metody routingu specyficzne dla protokołu AudioTrack i AudioRecord zajęć.

Szczegółowe informacje o interfejsie Enumeration and Selection API znajdziesz tutaj: Androida oraz OpenSLES_AndroidConfiguration.h. Więcej informacji o routingu dźwięku znajdziesz tutaj: Routing audio.

Pomoc dostępna w wielu kanałach

Jeśli Twój sprzęt i sterownik obsługują wielokanałowy dźwięk przez HDMI, wysyła strumień audio bezpośrednio do urządzenia audio (pomija to Miksera AudioFlinger w taki sposób, aby nie składał się z dwóch kanałów). HAL audio musi określać, czy profil strumienia wyjściowego obsługuje wielokanałową ścieżkę audio funkcje zabezpieczeń. Jeśli HAL ujawnia swoje możliwości, domyślny menedżer zasad umożliwia odtwarzanie wielokanałowe przez HDMI. Szczegóły implementacji znajdziesz w artykule device/samsung/tuna/audio/audio_hw.c

Aby określić, że produkt zawiera wielokanałowe wyjście audio, zmodyfikuj parametr plik konfiguracji zasad audio do opisu wyjścia wielokanałowego usługi. Oto przykład z: frameworks/av/services/audiopolicy/config/primary_audio_policy_configuration_tv.xml ma dynamiczną maskę kanału, co oznacza, że menedżer zasad dotyczących dźwięku wysyła zapytanie do kanału. maski obsługiwane przez ujście HDMI po nawiązaniu połączenia.

Możesz również określić statyczną maskę kanału, taką jak AUDIO_CHANNEL_OUT_5POINT1 Mikser AudioFlinger łączy w sobie automatycznie w trybie stereo przy wysyłaniu ich na urządzenie audio, które nie obsługują wielokanałową ścieżkę dźwiękową.

Kodeki multimediów

Upewnij się, że kodeki audio obsługiwane przez sprzęt i sterowniki działają prawidłowo zadeklarowanych dla Twojego produktu. Więcej informacji: Udostępnienie kodeków .