Połączone kierowanie urządzeń audio

Funkcja łączonego kierowania urządzeń audio umożliwia przesyłanie strumieniowe dźwięku na kilka 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 zniesione, aby umożliwić nowe zastosowania, takie jak nadawanie dźwięku, transmisja strumieniowa do grupy słuchawek audio BLE czy jednoczesne wybieranie kilku kart dźwiękowych USB. 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.

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, uzyskiwanie 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 audio, które można przekierować na to urządzenie, mogą wymagać otwarcia i sprawdzenia obsługiwanych atrybutów.

Podczas otwierania strumienia wyjściowego musisz 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ń wyjściowy nie może być obecnie kierowany na aktywne urządzenia.

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 dźwięku udostępnia tę listę interfejsów API systemu(zdefiniowanych w AudioManager.java):

  • setPreferredDeviceForStrategy

    Ustawia preferowane urządzenie do kierowania dźwięku w ramach danej strategii. Pamiętaj, że urządzenie może nie być dostępne w momencie ustawienia preferowanego urządzenia, ale będzie używane, gdy stanie się dostępne.

  • removePreferredDeviceForStrategy

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

  • getPreferredDeviceForStrategy

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

  • setPreferredDevicesForStrategy

    Ustawia preferowane urządzenia dla danej strategii.

  • getPreferredDevicesForStrategy

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

  • OnPreferredDevicesForStrategyChangedListener

    Definiuje 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 Audio dostawcy implementują interfejsy API, które obsługują raportowanie możliwości urządzenia. W tej sekcji opisano typy danych i metody używane do raportowania możliwości urządzenia oraz podano niektóre zmiany wprowadzone w bibliotece 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 z AudioProfile w przypadku znanych formatów audio lub z surowymi opisami sprzętu w przypadku formatów nieznanych platformie. Struktura AudioProfile zawiera format audio, częstotliwości próbkowania obsługiwane przez profil oraz listę masek kanału, 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.

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 (np. częstotliwości próbkowania, formatów, masek kanałów, kontrolerów wzmocnienia) dla danego portu audio.

Poniższy kod z 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 interfejsu audio_port_v7 wersja 3.2 starszego interfejsu API zawiera nowy interfejs API o nazwie get_audio_port_v7, który umożliwia wysyłanie zapytań 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);

Dane z używanej wcześniej wersji interfejsu API get_audio_port należy wypełnić w nowym formacie AudioPort, gdy starsza wersja interfejsu API jest starsza niż 3.2, a wersja HIDL HAL jest równa lub większa niż 7. W tym przypadku zakłada się, że wszystkie sformatowane stawki próbek 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 systemu setPreferredDevicesForStrategy, getPreferredDevicesForStrategy, removePreferredDeviceForStrategy i OnPreferredDevicesForStrategyChangedListener znajdziesz w metodzie PreferredDeviceRoutingTest w GTS.

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

Przykład implementacji funkcji get_audio_port_v7 znajduje się w audio_hal.c i pokazuje, jak zapytania o możliwości są kierowane do wielu urządzeń.

Weryfikacja

W tej sekcji znajdziesz informacje o weryfikacji Menedżera dźwięku w ramach CTS i GTS (Google Mobile Services Test Suite).

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 zawierają treści ze starszego, spłaszczonego formatu tablicy, ale są w nowym formacie AudioProfile.

  • AudioManagerTest#testPreferredDevicesForStrategy i AudioManagerTest#testPreferredDeviceForCapturePreset

    Sprawdź, czy testy API związane z preferowanymi urządzeniami i wstępnymi ustawieniami strategii zostały pomyślnie 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.