Funkcja połączonego routingu urządzeń audio dodaje obsługę strumieniowego przesyłania dźwięku do wielu urządzeń audio jednocześnie. Korzystając z tej funkcji, uprzywilejowane aplikacje mogą wybrać wiele preferowanych urządzeń dla określonej strategii za pomocą systemowych interfejsów API. Aplikacje mogą dokładniej odkrywać możliwości urządzeń audio, korzystając z publicznych interfejsów API udostępnianych przez tę funkcję. W przypadku Androida w wersji 11 i starszych implementacja struktury audio ma ograniczoną obsługę wielu urządzeń audio tego samego typu (na przykład 2 zestawów słuchawkowych Bluetooth A2DP) podłączonych jednocześnie. Domyślne reguły routingu audio również nie pozwalają użytkownikom na wybieranie wielu urządzeń tego samego typu dla danego przypadku użycia.
Począwszy od Androida 12, te ograniczenia zostały usunięte, aby umożliwić nowe zastosowania, takie jak transmisja audio, multiemisji do grupy słuchawek audio BLE lub jednoczesne wybieranie kilku kart dźwiękowych USB. Routing do wielu urządzeń USB jednocześnie nie jest obsługiwany.
Począwszy od Androida 14, środowisko USB obsługuje routing do wielu urządzeń USB, pod warunkiem, że urządzenia USB są urządzeniami audio różnych typów, a jądro i obsługa dostawców pozwalają na jednoczesne podłączenie wielu urządzeń USB.
Na tej stronie opisano, jak zaimplementować obsługę strumieniowego przesyłania dźwięku do wielu urządzeń audio oraz jak sprawdzić implementację tej funkcji.
Obsługa przesyłania strumieniowego dźwięku do wielu urządzeń audio
W systemie Android 12 dostępne są dwa zestawy interfejsów API obsługujące tę funkcję:
- Systemowe interfejsy API obsługują wiele preferowanych urządzeń w ramach strategii.
- Interfejs HIDL, zaimplementowany przez dostawcę jako część audio HAL, raportuje możliwości urządzenia.
W poniższych sekcjach omówiono bardziej szczegółowo każdy z tych interfejsów API.
Obsługuj wiele preferowanych urządzeń w ramach strategii
Menedżer zasad audio oferuje systemowe interfejsy API, które lepiej obsługują strumieniowe przesyłanie dźwięku do wielu urządzeń audio jednocześnie. Te systemowe interfejsy API umożliwiają ustawianie, pobieranie i usuwanie wielu preferowanych urządzeń dla danej strategii. Do wersji Androida 12 ta funkcja była obsługiwana tylko na jednym urządzeniu.
Menedżer zasad audio wprowadza koncepcję aktywnych urządzeń multimedialnych , aby opisać urządzenia, które najprawdopodobniej zostaną wybrane do odtwarzania multimediów. Po podłączeniu urządzenia odłączanego może być konieczne otwarcie i sprawdzenie wyjściowych strumieni audio HAL, które można skierować do tego urządzenia, pod kątem obsługiwanych atrybutów.
Podczas otwierania strumienia wyjściowego należy określić urządzenie audio. Aktywne urządzenie multimedialne to urządzenie używane, gdy strumienie wyjściowe są otwierane w tym kontekście.
Wybór aktywnego urządzenia multimedialnego może się zmieniać w zależności od aktualnie podłączonych lub odłączonych urządzeń. Menedżer zasad audio korzysta z następującej serii reguł przy wyborze aktywnych urządzeń multimedialnych:
- Jeśli wszystkie preferowane urządzenia dla multimediów są dostępne, wszystkie zostaną wybrane jako urządzenia aktywne.
- W przeciwnym razie wybrane zostanie ostatnie podłączone urządzenie wymienne.
- Jeśli nie są podłączone żadne urządzenia wymienne, do wybierania urządzeń aktywnych stosowane są domyślne zasady polityki audio dotyczące wyboru urządzeń wyjściowych.
Strumień wyjściowy musi spełniać następujące kryteria, aby został ponownie otwarty i przekierowany do aktywnych urządzeń, aby wybrać najlepszą konfigurację do odtwarzania:
- 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 do aktywnych urządzeń.
Aby zastosować nowy wybór urządzenia, Menedżer zasad audio zamyka i ponownie otwiera strumień wyjściowy po podłączeniu urządzenia, jeśli strumień wyjściowy jest bezczynny, lub odkłada go na czas przejścia strumienia wyjściowego w tryb gotowości.
Menedżer zasad audio oferuje następującą listę systemowych interfejsów API (zgodnie z definicją w AudioManager.java ):
setPreferredDeviceForStrategyUstawia preferowane urządzenie do routingu audio dla danej strategii. Należy pamiętać, że urządzenie może nie być dostępne w momencie ustawienia preferowanego urządzenia, ale będzie używane po udostępnieniu.
removePreferredDeviceForStrategyUsuwa preferowane urządzenia audio ustawione wcześniej za pomocą
setPreferredDeviceForStrategylubsetPreferredDevicesForStrategy.getPreferredDeviceForStrategyZwraca preferowane urządzenie dla strategii audio ustawionej wcześniej za pomocą
setPreferredDeviceForStrategylubsetPreferredDevicesForStrategy.setPreferredDevicesForStrategyUstawia preferowane urządzenia dla danej strategii.
getPreferredDevicesForStrategyZwraca preferowane urządzenia dla strategii audio ustawionej wcześniej za pomocą
setPreferredDeviceForStrategylubsetPreferredDevicesForStrategy.OnPreferredDevicesForStrategyChangedListenerDefiniuje interfejs powiadamiania o zmianach w preferowanych urządzeniach audio ustawionych dla danej strategii audio.
addOnPreferredDevicesForStrategyChangedListenerDodaje słuchacza, aby otrzymywać powiadomienia o zmianach w preferowanym przez strategię urządzeniu audio.
removeOnPreferredDevicesForStrategyChangedListenerUsuwa wcześniej dodany słuchacz zmian w preferowanym przez strategię urządzeniu audio.
Zgłoś możliwości urządzenia
W ramach implementacji Audio HAL dostawcy wdrażają interfejsy API obsługujące możliwości urządzeń raportujących. W tej sekcji wyjaśniono typy danych i metody używane do raportowania możliwości urządzeń oraz wymieniono niektóre zmiany wprowadzone w audio HIDL HAL V7 w celu obsługi wielu urządzeń.
Typy danych
W audio HIDL HAL V7 możliwości urządzenia są raportowane przy użyciu struktur AudioProfile i AudioTransport . Struktura AudioTransport opisuje możliwości portu audio z AudioProfile dla znanych formatów audio lub z surowymi deskryptorami sprzętowymi dla formatów, które nie są znane platformie. Struktura AudioProfile zawiera format audio, częstotliwości próbkowania obsługiwane przez profil oraz listę masek kanałów, jak pokazano w następującym 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 audio HIDL HAL V7 typ danych AudioPort jest zdefiniowany za pomocą struktur AudioTransport i AudioProfile w celu opisania możliwości urządzenia.
Metody audio HAL
Menedżer zasad audio używa następujących metod do sprawdzania możliwości urządzenia:
-
getParameters:Ogólna metoda pobierania wartości parametrów specyficznych dla dostawcy, takich jak obsługiwane formaty audio i odpowiadające im częstotliwości próbkowania. -
getAudioPort:Zwraca listę obsługiwanych atrybutów (takich jak częstotliwość próbkowania, formaty, maski kanałów, kontrolery wzmocnienia) dla danego portu audio.
Poniższy kod z IDevice.hal przedstawia 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 dotychczasowym interfejsie API
Aby obsługiwać wiele profili audio, wersja 3.2 starszego interfejsu API dodaje nową strukturę o nazwie audio_port_v7 . Więcej szczegółów znajdziesz w kodzie źródłowym .
Dzięki dodaniu audio_port_v7 wersja 3.2 starszego interfejsu API dodaje nowy interfejs API o nazwie get_audio_port_v7 do sprawdzania możliwości urządzeń przy użyciu struktury audio_port_v7 .
Poniższy kod z audio.h przedstawia definicję 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 ze starszego interfejsu API get_audio_port należy wprowadzić do nowego formatu AudioPort , jeśli starsza wersja interfejsu API jest niższa niż 3.2, a wersja HIDL HAL to 7 lub wyższa. W tym przypadku zakłada się, że wszystkie raportowane częstotliwości próbkowania i maski kanałów z get_audio_port są obsługiwane dla wszystkich zwracanych formatów, umożliwiając proste mapowanie wartości get_audio_port na nową strukturę AudioPort .
Przykładowe wdrożenia API
W tej sekcji opisano kilka zestawów testów zawierających metody korzystające z interfejsów API omówionych w poprzednich sekcjach. Zapoznaj się z tymi metodami, aby zapoznać się z przykładami implementacji i używania tych interfejsów API.
Przykład wykorzystania systemowych API setPreferredDevicesForStrategy , getPreferredDevicesForStrategy , removePreferredDeviceForStrategy i OnPreferredDevicesForStrategyChangedListener znajduje się w metodzie PreferredDeviceRoutingTest , która znajduje się w GTS.
Aby zobaczyć przykład nowej struktury w AudioDeviceInfo w użyciu, zobacz metodę AudioManagerTest#testGetDevices , która znajduje się w CTS.
Przykład implementacji get_audio_port_v7 znajduje się w audio_hal.c i pokazuje, w jaki sposób sprawdzane są możliwości wielu urządzeń.
Walidacja
W tej sekcji znajdują się informacje na temat sprawdzania poprawności Menedżera audio przez CTS i GTS (Google Mobile Services Test Suite).
Testy CTS
Testy CTS znajdują się w android.media.cts.AudioManagerTest .
Poniżej znajduje się lista dostępnych testów Menedżera audio:
AudioManagerTest#testGetDevicesWeryfikuje dokładne możliwości urządzenia audio. Sprawdza również, czy zwrócone profile audio w strukturze
AudioDeviceInfozachowują zawartość ze starszego, spłaszczonego formatu tablicy, ale są w nowym formacieAudioProfile.AudioManagerTest#testPreferredDevicesForStrategyiAudioManagerTest#testPreferredDeviceForCapturePresetSprawdź, czy preferowane urządzenia do testów API związanych ze strategią i przechwytywaniem zakończyły się pomyślnie.
Testy GTS
Testy GTS znajdują się w com.google.android.gts.audioservice.AudioServiceHostTest .
Aby sprawdzić, czy interfejsy API preferowanych urządzeń dla strategii i ustawień wstępnych przechwytywania działają poprawnie, uruchom testy AudioServiceHostTest#testPreferredDeviceRouting i AudioServiceHostTest#testPreferredDeviceRoutingForCapturePreset .