Połączone kierowanie urządzeń audio

Połączona funkcja routingu urządzeń audio umożliwia strumieniowanie dźwięku na wiele urządzeń audio jednocześnie. Dzięki tej funkcji aplikacje z uprawnieniami mogą wybierać kilka preferowanych urządzeń do określonej strategii za pomocą interfejsów systemowych. Aplikacje mogą dokładniej wykrywać możliwości urządzeń audio, korzystając z publicznych interfejsów API udostępnianych przez tę funkcję. W przypadku wersji Androida 11 i starszych implementacja ramki audio ma ograniczone wsparcie dla wielu urządzeń audio tego samego typu (np. 2 słuchawki Bluetooth A2DP) połączonych jednocześnie. Domyślne reguły przekierowywania dźwięku nie pozwalają też użytkownikom na wybranie kilku urządzeń tego samego typu w danym przypadku użycia.

Począwszy od Androida 12 te ograniczenia zostały usunięte, aby umożliwić korzystanie w nowych przypadkach użycia, takich jak transmisja dźwięku, multicasting na grupę słuchawek audio BLE lub wybór kilku kart dźwiękowych USB jednocześnie. Przekierowywanie do wielu urządzeń USB jednocześnie nie jest obsługiwane.

Począwszy od Androida 14, platforma USB obsługuje przekierowywanie do wielu urządzeń USB, o ile są to urządzenia audio różnych typów. Kernel i urządzenia obsługują jednoczesne połączenie wielu urządzeń USB.

Na tej stronie znajdziesz informacje o tym, jak wdrożyć obsługę strumieniowego przesyłania dźwięku na wiele urządzeń audio oraz jak zweryfikować implementację tej funkcji.

Uwaga: ta funkcja jest implementowana tylko w AOSP. Niektóre testy znajdują się w GTS, który nie jest dostępny w AOSP.

Obsługa strumieniowego przesyłania dźwięku na wiele urządzeń audio

W Androidzie 12 są 2 zbiory interfejsów API, które obsługują tę funkcję:

• Interfejsy API systemu obsługują wiele preferowanych urządzeń w ramach strategii.
• Interfejs HIDL, zaimplementowany przez dostawcę jako część HAL audio, informuje o możliwościach urządzenia.

W następnych sekcjach omawiamy szczegółowo poszczególne interfejsy API.

Obsługa wielu preferowanych urządzeń w ramach strategii

Menedżer zasad dotyczących dźwięku udostępnia interfejsy API systemu, aby lepiej obsługiwać strumieniowe przesyłanie dźwięku do wielu urządzeń audio jednocześnie. Te interfejsy API systemu umożliwiają konfigurowanie, pobieranie i usuwanie kilku preferowanych urządzeń w ramach danej strategii. Do Androida 12 ta funkcja była obsługiwana tylko na jednym urządzeniu.

Menedżer zasad dotyczących dźwięku wprowadza pojęcie aktywnych urządzeń multimedialnych, aby opisać urządzenia, które są najbardziej prawdopodobne do wybrania do odtwarzania multimediów. Gdy podłączone jest urządzenie wymienne, strumienie wyjściowe HAL dźwięku, które można przekierować na to urządzenie, mogą wymagać otwarcia i sprawdzenia obsługiwanych atrybutów.

Uwaga: jeśli obsługiwany jest dynamiczny profil audio, a nie wszystkie aktywne ścieżki zostaną przekierowane, strumień wyjściowy nie zostanie ponownie otwarty od razu po podłączeniu urządzenia, ale później, gdy wszystkie ścieżki staną się nieaktywne.

Przy otwieraniu strumienia wyjściowego należy określić urządzenie audio. Aktywne urządzenie multimedialne to urządzenie używane podczas otwierania strumieni danych wyjściowych w tym kontekście.

Wybór aktywnego urządzenia multimedialnego może się zmieniać w zależności od tego, które urządzenia są połączone lub odłączone. Menedżer zasad dotyczących dźwięku używa tej serii reguł do wybierania aktywnych urządzeń multimedialnych:

1. Jeśli wszystkie preferowane urządzenia do multimediów są dostępne, wszystkie są wybierane jako aktywne.
2. W przeciwnym razie wybrane zostanie ostatnie podłączone urządzenie wymienne.
3. Jeśli nie ma podłączonych urządzeń wymiennych, do wyboru urządzeń aktywnych są stosowane domyślne reguły zasad dotyczących dźwięku.

Aby strumień wyjściowy można było ponownie otworzyć i przekierować na aktywne urządzenia, tak aby wybrano najlepszą konfigurację do odtwarzania, musi on spełniać te kryteria:

• Strumień wyjściowy musi obsługiwać aktywne urządzenia.
• Strumień wyjściowy musi obsługiwać profile dynamiczne.
• Strumień danych wyjściowych nie może obecnie być kierowany do aktywnych urządzeń.

Aby zastosować nowy wybór urządzenia, Menedżer zasad dotyczących dźwięku zamyka i ponownie otwiera strumień wyjściowy po połączeniu urządzenia, jeśli strumień wyjściowy jest nieaktywny, lub odkłada to na czas, gdy strumień wyjściowy zostanie umieszczony w stanie gotowości.

Menedżer zasad dotyczących audio udostępnia tę listę systemowych interfejsów API(zdefiniowanych w AudioManager.java):

• setPreferredDeviceForStrategy

  Ustawia preferowane urządzenie do kierowania dźwięku w ramach danej strategii. Pamiętaj, że w momencie ustawienia preferowanego urządzenia urządzenie może być niedostępne, ale będzie ono używane po jego udostępnieniu.

• removePreferredDeviceForStrategy

  Usuwa preferowane urządzenia audio wcześniej ustawione za pomocą ustawienia setPreferredDeviceForStrategy lub setPreferredDevicesForStrategy.

• getPreferredDeviceForStrategy

  Zwraca preferowane urządzenie dla strategii audio ustawionej wcześniej za pomocą setPreferredDeviceForStrategy lub setPreferredDevicesForStrategy.

• setPreferredDevicesForStrategy

  Ustawia preferowane urządzenia w przypadku danej strategii.

• getPreferredDevicesForStrategy

  Zwraca preferowane urządzenia dla strategii audio ustawionej wcześniej za pomocą setPreferredDeviceForStrategy lub setPreferredDevicesForStrategy.

• OnPreferredDevicesForStrategyChangedListener

  Określa interfejs do powiadamiania o zmianach w ustawionych preferowanych urządzeniach audio dla danej strategii audio.

• addOnPreferredDevicesForStrategyChangedListener

  Dodaje słuchacza, aby otrzymywać powiadomienia o zmianach w preferowanym przez strategię urządzeniu audio.

• removeOnPreferredDevicesForStrategyChangedListener

  Usuwa wcześniej dodanego słuchacza zmian w preferowanym przez strategię urządzeniu audio.

Raportowanie możliwości urządzenia

W ramach implementacji interfejsu HAL dla dźwięku dostawcy implementują interfejsy API, które obsługują raportowanie możliwości urządzenia. W tej sekcji opisujemy typy i metody danych używane do raportowania możliwości urządzenia, a także wymieniamy zmiany w interfejsie audio HIDL HAL V7 w celu obsługi wielu urządzeń.

Typy danych

W HIDL HAL w wersji 7 stosowanej do dźwięku możliwości urządzenia są zgłaszane za pomocą struktur AudioProfile i AudioTransport. Struktura AudioTransport opisuje możliwości portu audio za pomocą AudioProfile w przypadku znanych formatów audio lub za pomocą surowych deskryptorów sprzętowych w przypadku formatów nieznanych platformie. Struktura AudioProfile zawiera format audio, częstotliwości próbkowania obsługiwane przez profil oraz listę masek kanałów, jak pokazano w tym bloku kodu z types.hal:

/**
* Configurations supported for a certain audio format.
*/
struct AudioProfile {
   AudioFormat format;
   /** List of the sample rates (in Hz) supported by the profile. */
   vec<uint32_t> sampleRates;
   /** List of channel masks supported by the profile. */
   vec<AudioChannelMask> channelMasks;
};

W HIDL HAL V7 typ danych AudioPort jest definiowany za pomocą struktur AudioTransport i AudioProfile, które opisują możliwości urządzenia.

Uwaga: w przedsprzedaży na Androida 12 struktura AudioDeviceInfo interfejsu SDK opisuje możliwości związane z dźwiękiem, takie jak współczynniki próbkowania, formaty i maski kanałów w spłaszczonym formacie tablicy, w którym brakuje wyraźnej zależności między formatem i częstotliwościami próbkowania a maskami kanałów. Usługa AudioProfile została zastąpiona przez Androida 12 zgodnie z definicją powyżej.

Metody interfejsu HAL dźwięku

Menedżer zasad dotyczących dźwięku używa tych metod do zapytania o możliwości urządzenia:

• getParameters:Ogólna metoda pobierania wartości parametrów specyficznych dla dostawcy, takich jak obsługiwane formaty audio i odpowiednie częstotliwości próbkowania.
• getAudioPort:Zwraca listę obsługiwanych atrybutów (takich jak częstotliwość próbkowania, formaty, maski kanałów czy kontrolery wzmocnienia) danego portu audio.

Poniższy kod z metody IDevice.hal pokazuje interfejs metody getAudioPort:

   /**
    * Returns the list of supported attributes for a given audio port.
    *
    * As input, 'port' contains the information (type, role, address etc...)
    * needed by the HAL to identify the port.
    *
    * As output, 'resultPort' contains possible attributes (sampling rates,
    * formats, channel masks, gain controllers...) for this port.
    *
    * @param port port identifier.
    * @return retval operation completion status.
    * @return resultPort port descriptor with all parameters filled up.
    */
   getAudioPort(AudioPort port)
           generates (Result retval, AudioPort resultPort);

Zmiany w starszym interfejsie API

Aby obsługiwać wiele profili audio, wersja 3.2 starszego interfejsu API zawiera nową strukturę o nazwie audio_port_v7. Więcej informacji znajdziesz w kodzie źródłowym.

Ze względu na dodanie audio_port_v7 w wersji 3.2 starszej wersji interfejsu API dodaliśmy nowy interfejs API o nazwie get_audio_port_v7, który wysyła zapytania o możliwości urządzeń za pomocą struktury audio_port_v7.

Ten kod z audio.h pokazuje definicję interfejsu API get_audio_port_v7:

/**
 * Fills the list of supported attributes for a given audio port.
 * As input, "port" contains the information (type, role, address etc...)
 * needed by the HAL to identify the port.
 * As output, "port" contains possible attributes (sampling rates,
 * formats, channel masks, gain controllers...) for this port. The
 * possible attributes are saved as audio profiles, which contains audio
 * format and the supported sampling rates and channel masks.
 */
 int (*get_audio_port_v7)(struct audio_hw_device *dev,
                          struct audio_port_v7 *port);

Uwaga: interfejs getAudioPort API wywołuje interfejs get_audio_port_v7 API tylko wtedy, gdy wersja interfejsu HIDL HAL dla dźwięku to 7 lub nowsza, a wersja starszego interfejsu API to 3.2 lub nowsza. W przypadku wersji interfejsu audio HIDL HAL 6 lub starszych oraz starszych wersji interfejsu API poniżej wersji 3.2 interfejs getAudioPort zamiast tego wywołuje interfejs API get_audio_port, aby sprawdzić możliwości urządzenia.

Gdy starsza wersja interfejsu API jest niższa niż 3.2, a wersja HIDL HAL 7 lub nowsza, dane ze starszej wersji interfejsu API get_audio_port trzeba wstawić w nowym formacie AudioPort. W tym przypadku zakłada się, że wszystkie sformatowane stawki i maski kanałów z get_audio_port są obsługiwane w przypadku wszystkich zwracanych formatów, co umożliwia proste mapowanie wartości get_audio_port na nową strukturę AudioPort.

Przykładowe implementacje interfejsu API

W tej sekcji opisaliśmy kilka zestawów testów zawierających metody korzystające z interfejsów API omawianych w poprzednich sekcjach. W przypadku tych metod znajdziesz przykłady implementacji i użycia tych interfejsów API.

Przykład użycia interfejsów API systemowych setPreferredDevicesForStrategy, getPreferredDevicesForStrategy, removePreferredDeviceForStrategy i OnPreferredDevicesForStrategyChangedListener znajduje się w metodzie PreferredDeviceRoutingTest w GTS.

Przykład nowej struktury w użyciu w AudioDeviceInfo znajdziesz w metodzie AudioManagerTest#testGetDevices w CTS.

Uwaga: kod CTS tej implementacji zostanie udostępniony publicznie w Androidzie 12.

Przykład implementacji funkcji get_audio_port_v7 znajduje się w audio_hal.c i pokazuje, jak pobierać informacje o możliwościach na wielu urządzeniach.

Weryfikacja

Ta sekcja zawiera informacje o weryfikacji CTS i GTS (Google Mobile Services Test Suite) w Menedżerze audio.

Uwaga: GTS jest oprogramowaniem zamkniętym i zawiera bardziej kompleksowe testy preferowanych urządzeń z API niż CTS. Aby zwiększyć zakres testów, uruchom też testy CTS.

Testy CTS

Testy CTS znajdują się w android.media.cts.AudioManagerTest.

Oto lista dostępnych testów w Menedżerze audio:

• AudioManagerTest#testGetDevices

  Weryfikuje dokładne możliwości urządzenia audio. Sprawdza też, czy zwrócone profile audio w strukturze AudioDeviceInfo zachowują zawartość ze starszego, spłaszczonego formatu tablicy, ale są zapisane w nowym formacie AudioProfile.

  Uwaga: zwrócona tablica AudioProfile z wywołania AudioDeviceInfo#getAudioProfiles() musi zawierać te same dane co spłaszczone tablice z wywołań AudioDeviceInfo#getEncodings(), AudioDeviceInfo#getSampleRates() i AudioDeviceInfo#getChannelMasks().

• AudioManagerTest#testPreferredDevicesForStrategy i AudioManagerTest#testPreferredDeviceForCapturePreset

  Sprawdź, czy preferowane urządzenia do strategii i przechwytywania gotowych testów interfejsu API zostały ukończone.

Testy GTS

Testy GTS znajdują się w com.google.android.gts.audioservice.AudioServiceHostTest.

Aby sprawdzić, czy interfejsy API preferowanych urządzeń dla strategii i wstępnie ustawionych przechwytywania działają prawidłowo, wykonaj testy AudioServiceHostTest#testPreferredDeviceRouting i AudioServiceHostTest#testPreferredDeviceRoutingForCapturePreset.