Funkcja routingu dźwięku na wiele urządzeń dodaje obsługę strumieniowego przesyłania dźwięku na kilka urządzeń audio jednocześnie. Dzięki tej funkcji uprzywilejowane aplikacje mogą wybierać wiele preferowanych urządzeń dla konkretnej strategii za pomocą interfejsów API systemu. Aplikacje mogą dokładniej wykrywać możliwości urządzeń audio za pomocą publicznych interfejsów API udostępnianych przez tę funkcję. W przypadku Androida w wersji 11 i starszych implementacja struktury audio ma ograniczone możliwości obsługi wielu urządzeń audio tego samego typu (np. 2 zestawów słuchawkowych Bluetooth A2DP) połączonych jednocześnie. Domyślne reguły routingu audio nie pozwalają też użytkownikom wybierać wielu urządzeń tego samego typu w określonym przypadku użycia.
Od Androida 12 te ograniczenia zostały usunięte, aby umożliwić nowe zastosowania, takie jak transmisja audio, multiemisja do grupy słuchawek Bluetooth LE lub jednoczesne wybieranie kilku kart dźwiękowych USB. Przekierowywanie do wielu urządzeń USB jednocześnie nie jest obsługiwane.
Od Androida 14 struktura USB obsługuje kierowanie do wielu urządzeń USB, pod warunkiem że są to urządzenia audio różnych typów i że jądro oraz dostawca obsługują jednoczesne łączenie wielu urządzeń USB.
Na tej stronie znajdziesz informacje o tym, jak wdrożyć obsługę przesyłania strumieniowego dźwięku do wielu urządzeń audio i jak sprawdzić, czy ta funkcja działa prawidłowo.
obsługiwać strumieniowanie dźwięku na wiele urządzeń audio;
W Androidzie 12 są 2 zestawy interfejsów API, które obsługują tę funkcję:
- Interfejsy API systemu obsługują wiele preferowanych urządzeń w przypadku strategii.
- Interfejs HIDL, zaimplementowany przez dostawcę jako część HAL audio, raportuje możliwości urządzenia.
W kolejnych sekcjach znajdziesz szczegółowe informacje o każdym z tych interfejsów API.
Obsługa wielu preferowanych urządzeń w przypadku strategii
Menedżer zasad audio udostępnia interfejsy API systemu, które lepiej obsługują przesyłanie strumieniowe dźwięku do wielu urządzeń audio jednocześnie. Te interfejsy API systemu umożliwiają ustawianie, pobieranie i usuwanie wielu preferowanych urządzeń w przypadku danej strategii. Do Androida 12 ta funkcja była obsługiwana tylko na jednym urządzeniu.
Menedżer zasad audio wprowadza pojęcie aktywnych urządzeń multimedialnych, aby opisać urządzenia, które najprawdopodobniej zostaną wybrane do odtwarzania multimediów. Gdy podłączone jest urządzenie odłączane, strumienie wyjściowe HAL audio, które można przekierować do tego urządzenia, mogą wymagać otwarcia i sprawdzenia pod kątem obsługiwanych atrybutów.
Podczas otwierania strumienia wyjściowego musisz określić urządzenie audio. Aktywne urządzenie multimedialne to urządzenie używane, gdy w tym kontekście otwierane są strumienie wyjściowe.
Wybór aktywnego urządzenia multimedialnego może się zmieniać w zależności od tego, które urządzenia są podłączone, a które nie. Menedżer zasad audio korzysta z tych reguł, aby wybrać aktywne urządzenia multimedialne:
- Jeśli wszystkie preferowane urządzenia do odtwarzania multimediów są dostępne, zostaną wybrane jako aktywne.
- W przeciwnym razie zostanie wybrane ostatnio podłączone urządzenie wymienne.
- Jeśli nie ma podłączonych urządzeń wymiennych, do wyboru aktywnych urządzeń stosowane są domyślne reguły zasad audio dotyczące wyboru urządzeń wyjściowych.
Strumień wyjściowy musi spełniać te kryteria, aby można było go ponownie otworzyć i przekierować na aktywne urządzenia, tak aby do odtwarzania została wybrana najlepsza konfiguracja:
- 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 audio zamyka i ponownie otwiera strumień wyjściowy po podłączeniu urządzenia, jeśli strumień wyjściowy jest bezczynny, lub odkłada to na moment, gdy strumień wyjściowy zostanie przełączony w tryb gotowości.
Menedżer zasad audio udostępnia tę listę interfejsów API systemu(zgodnie z definicją w AudioManager.java):
setPreferredDeviceForStrategyUstawia preferowane urządzenie do kierowania dźwięku w przypadku danej strategii. Pamiętaj, że urządzenie może być niedostępne w momencie ustawiania preferowanego urządzenia, ale będzie używane, gdy stanie się dostępne.
removePreferredDeviceForStrategyUsuwa preferowane urządzenia audio ustawione wcześniej za pomocą funkcji
setPreferredDeviceForStrategylubsetPreferredDevicesForStrategy.getPreferredDeviceForStrategyZwraca preferowane urządzenie dla strategii audio ustawionej wcześniej za pomocą funkcji
setPreferredDeviceForStrategylubsetPreferredDevicesForStrategy.setPreferredDevicesForStrategyUstawia preferowane urządzenia dla danej strategii.
getPreferredDevicesForStrategyZwraca preferowane urządzenia dla strategii audio, które zostały wcześniej ustawione za pomocą funkcji
setPreferredDeviceForStrategylubsetPreferredDevicesForStrategy.OnPreferredDevicesForStrategyChangedListenerDefiniuje interfejs powiadamiania o zmianach preferowanych urządzeń audio ustawionych dla danej strategii audio.
addOnPreferredDevicesForStrategyChangedListenerDodaje odbiorcę, który będzie otrzymywać powiadomienia o zmianach preferowanego urządzenia audio w strategii.
removeOnPreferredDevicesForStrategyChangedListenerUsuwa wcześniej dodany odbiornik zmian preferowanego urządzenia audio strategii.
Raportowanie możliwości urządzenia
W ramach implementacji HAL audio dostawcy wdrażają interfejsy API, które obsługują raportowanie możliwości urządzenia. W tej sekcji opisujemy typy danych i metody używane do raportowania możliwości urządzenia oraz wymieniamy niektóre zmiany wprowadzone w interfejsie HIDL HAL audio w wersji 7, aby obsługiwać wiele urządzeń.
Typy danych
W przypadku interfejsu HIDL HAL V7 audio 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, które nie są znane platformie. Struktura AudioProfile zawiera format audio, częstotliwości próbkowania obsługiwane przez profil i 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 interfejsie HIDL HAL V7 audio typ danych AudioPort jest zdefiniowany za pomocą struktur AudioTransport i AudioProfile, aby opisywać możliwości urządzenia.
Metody HAL audio
Menedżer zasad audio korzysta z tych metod, aby wysyłać 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ści próbkowania, formaty, maski kanałów, kontrolery 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 starszej wersji interfejsu API
Aby obsługiwać wiele profili audio, w wersji 3.2 starszego interfejsu API dodaliśmy nową strukturę o nazwie audio_port_v7. Więcej informacji znajdziesz w kodzie źródłowym.
W związku z dodaniem 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.
Poniższy kod z audio.h
zawiera 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 ze starszego interfejsu get_audio_port API muszą być wypełniane w nowym formacie AudioPort, gdy starsza wersja interfejsu API jest starsza niż 3.2, a wersja HIDL HAL to 7 lub nowsza. W tym przypadku zakłada się, że wszystkie zgłoszone częstotliwości próbkowania i maski kanałów z get_audio_port są obsługiwane we wszystkich zwracanych formatach, co umożliwia proste mapowanie wartości z get_audio_port na nową strukturę AudioPort.
Przykładowe implementacje interfejsu API
W tej sekcji opisujemy kilka pakietów testowych zawierających metody korzystające z interfejsów API omówionych w poprzednich sekcjach. Przykłady implementacji i użycia tych interfejsów API znajdziesz w tych metodach.
Przykład użycia interfejsów API systemu setPreferredDevicesForStrategy, getPreferredDevicesForStrategy, removePreferredDeviceForStrategy i OnPreferredDevicesForStrategyChangedListener znajduje się w metodzie PreferredDeviceRoutingTest w GTS.
Przykład użycia nowej struktury w AudioDeviceInfo znajdziesz w metodzie AudioManagerTest#testGetDevices w CTS.
Przykład implementacji get_audio_port_v7 znajduje się w
audio_hal.c
i pokazuje, jak wysyłać zapytania o możliwości wielu urządzeń.
Weryfikacja
W tej sekcji znajdziesz informacje o weryfikacji Menedżera dźwięku za pomocą CTS i GTS (pakietu testów usług mobilnych Google).
Testy CTS
Testy CTS znajdują się w android.media.cts.AudioManagerTest.
Oto lista dostępnych testów Menedżera audio:
AudioManagerTest#testGetDevicesWeryfikuje dokładne możliwości urządzenia audio. Sprawdza też, czy zwrócone profile audio w strukturze
AudioDeviceInfozachowują zawartość ze starszego, spłaszczonego formatu tablicy, ale są w nowym formacieAudioProfile.AudioManagerTest#testPreferredDevicesForStrategyiAudioManagerTest#testPreferredDeviceForCapturePresetSprawdź, czy testy API związane z ustawieniami wstępnymi strategii i przechwytywania na preferowanych urządzeniach 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 ustawień wstępnych przechwytywania działają prawidłowo, przeprowadź testy AudioServiceHostTest#testPreferredDeviceRouting i AudioServiceHostTest#testPreferredDeviceRoutingForCapturePreset.