Połączone kierowanie urządzeń audio

Połączona funkcja routingu urządzeń audio zapewnia obsługę strumieniowania dźwięku na wielu urządzeniach audio jednocześnie. Dzięki tej funkcji aplikacje z podwyższonymi uprawnieniami mogą wybieranie wielu preferowanych urządzeń na potrzeby konkretnej strategii. za pomocą systemowych interfejsów API. Aplikacje mogą lepiej 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 platformy audio ograniczona obsługa wielu urządzeń audio tego samego typu (np. 2 zestawy słuchawkowe Bluetooth A2DP) podłączone jednocześnie. Domyślny routing audio ale reguły nie pozwalają też użytkownikom wybrać wielu urządzeń tego samego typu w danym przypadku użycia.

Te ograniczenia są usuwane od Androida 12 aby umożliwić korzystanie z nowych przypadków użycia, takich jak transmisja dźwięku i multicasting do grupy. słuchawek audio BLE lub wybranie kilku kart dźwiękowych USB naraz. Routing do wielu urządzeń USB jednocześnie nie jest obsługiwany.

Od Androida 14 platforma USB obsługuje kierowanie ruchu do wielu urządzeń USB, pod warunkiem że urządzenia USB mają różne dźwięki typu urządzenia. Można ją też połączyć, korzystając z jądra systemu i pomocy dostawcy. urządzenia jednocześnie.

Na tej stronie opisujemy, jak wdrożyć obsługę strumieniowego przesyłania dźwięku wiele urządzeń audio i jak sprawdzić poprawność implementacji tej funkcji.

Obsługa strumieniowania dźwięku na wiele urządzeń audio

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

  • Systemowe interfejsy API obsługują wiele preferowanych urządzeń w ramach strategii.
  • Interfejs HIDL wdrożony przez dostawcę w ramach karty HAL audio. raportuje możliwości urządzenia.

W kolejnych sekcjach szczegółowo opisujemy każdy z tych interfejsów API.

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

Menedżer zasad dotyczących dźwięku oferuje systemowe interfejsy API, które usprawniają obsługę z kilku urządzeń audio jednocześnie. Te systemowe interfejsy API włączają ustawienie, pobierając i usunięcie wielu 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, to urządzenia, które najprawdopodobniej będą wybierane do odtwarzania multimediów. Kiedy jeśli podłączone jest urządzenie hybrydowe, wyjście audio HAL strumieniuje, kierowane na to urządzenie mogą wymagać otwarcia i sprawdzenia obsługiwanych atrybutów.

Przy otwieraniu strumienia wyjściowego należy określić urządzenie audio. Aktywny 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 urządzenia połączone lub odłączone. W Menedżerze zasad dotyczących reklam audio są używane następujące serie: reguł do wybierania aktywnych urządzeń multimedialnych:

  1. Jeśli dostępne są wszystkie preferowane urządzenia do multimediów, zostaną one wybrane jako aktywne urządzenia.
  2. W przeciwnym razie wybierane jest ostatnio podłączone urządzenie wymienne.
  3. Jeśli nie ma podłączonych żadnych urządzeń wymiennych, domyślne reguły zasad audio urządzenia wyjściowego są stosowane do wybierania aktywnych urządzeń.

Strumień danych wyjściowych musi spełniać poniższe kryteria, aby został ponownie otwarty i przekierowany z aktywnych urządzeń, aby wybrać najlepszą konfigurację do odtwarzania:

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

Aby zastosować wybrane nowe urządzenie, Menedżer zasad dotyczących dźwięku zamyka ponownie otwiera strumień wyjściowy po połączeniu urządzenia, jeśli strumień wyjściowy jest nieaktywny lub opóźnia jego działanie, gdy strumień wyjściowy znajdzie się w trybie gotowości.

Menedżer zasad dotyczących audio oferuje następującą listę systemowych interfejsów API(zdefiniowanych w AudioManager.java):

  • setPreferredDeviceForStrategy

    Ustawia preferowane urządzenie do routingu dźwięku w przypadku danej strategii. Notatka że urządzenie może być niedostępne w czasie, gdy preferowane ale jest używany po udostępnieniu.

  • removePreferredDeviceForStrategy

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

  • getPreferredDeviceForStrategy

    Zwraca preferowane urządzenie w przypadku strategii dotyczącej dźwięku ustawionej wcześniej za pomocą: setPreferredDeviceForStrategy lub setPreferredDevicesForStrategy.

  • setPreferredDevicesForStrategy

    Ustawia preferowane urządzenia w przypadku danej strategii.

  • getPreferredDevicesForStrategy

    Zwraca preferowane urządzenia w przypadku strategii dotyczącej dźwięku ustawionej wcześniej za pomocą: setPreferredDeviceForStrategy lub setPreferredDevicesForStrategy.

  • OnPreferredDevicesForStrategyChangedListener

    Definiuje interfejs powiadomień o zmianach w preferowanym dźwięku urządzeń ustawionych na potrzeby danej strategii dotyczącej dźwięku.

  • addOnPreferredDevicesForStrategyChangedListener

    Dodaje detektora, który będzie otrzymywać powiadomienia o zmianach w dźwięku preferowanym w strategii urządzenia.

  • removeOnPreferredDevicesForStrategyChangedListener

    Usuwa wcześniej dodany detektor zmian preferowanych w strategii. urządzenia audio.

Raportowanie możliwości urządzenia

W ramach implementacji interfejsu Audio HAL dostawcy wdrażają interfejsy API, które raportowania możliwości urządzeń. W tej sekcji opisujemy typy i metody danych. służy do raportowania możliwości urządzenia i zawiera niektóre zmiany wprowadzone w interfejsie HAL audio HIDL w wersji 7, która obsługuje wiele urządzeń.

Typy danych

W przypadku audio HIDL HAL V7 możliwości urządzenia są raportowane za pomocą parametru AudioProfile i AudioTransport. Struktura AudioTransport opisuje możliwości portu audio z AudioProfile w przypadku znanych formatów audio lub nieprzetworzone deskryptory sprzętowe dla formatów nieznanych przez platformę. Struktura AudioProfile zawiera format audio, obsługiwane częstotliwości próbkowania według profilu i listy masek kanałów, jak pokazano w poniższym kodzie zablokuj od 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 przypadku audio HIDL HAL V7 typ danych AudioPort jest zdefiniowany w parametrze struktury AudioTransport i AudioProfile opisujące funkcje zabezpieczeń.

Metody HAL audio

Menedżer zasad dotyczących dźwięku wysyła zapytania dotyczące funkcje:

  • getParameters:Ogólna metoda pobierania parametrów konkretnego dostawcy takich jak obsługiwane formaty audio i odpowiadające im współczynniki próbkowania.
  • getAudioPort:Zwraca listę obsługiwanych atrybutów (takich jak próbkowanie szybkości, formaty, maski kanałów czy kontrolery wzmocnienia) dla danego portu audio.

Następujący 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 zapewnić obsługę wielu profili audio, w wersji 3.2 starszej wersji interfejsu API dodaliśmy nowy o nazwie audio_port_v7. Zobacz kod źródłowy .

W związku z dodaniem interfejsu audio_port_v7 w wersji 3.2 starszej wersji interfejsu API dodaje się o nazwie get_audio_port_v7, aby wysyłać zapytania o możliwości urządzeń za pomocą Struktura audio_port_v7.

Następujący 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 ze starszej wersji interfejsu API get_audio_port trzeba uzupełnić w nowym miejscu AudioPort, gdy starsza wersja interfejsu API jest niższa niż 3.2, a wartość HAL HIDL w wersji 7 lub nowszej. W tym przypadku wszystkie raportowane współczynniki próbkowania i kanały maski z get_audio_port zakłada się, że są obsługiwane dla wszystkich zwracanych formatów, co umożliwia łatwe mapowanie wartości z get_audio_port na nowa struktura AudioPort.

Przykładowe implementacje interfejsu API

W tej sekcji opisujemy kilka zestawów testów zawierających metody korzystające z interfejsów API omówione we wcześniejszych sekcjach. Oto kilka przykładów tych metod jak implementować i używać tych interfejsów API.

Przykład użycia setPreferredDevicesForStrategy, getPreferredDevicesForStrategy, removePreferredDeviceForStrategy i Systemowe interfejsy API OnPreferredDevicesForStrategyChangedListener znajdują się w PreferredDeviceRoutingTest metody, która znajduje się w GTS.

Aby zobaczyć przykład nowej struktury w użyciu AudioDeviceInfo, zapoznaj się z AudioManagerTest#testGetDevices, która znajduje się w narzędziu CTS.

Przykład implementacji get_audio_port_v7 znajduje się tutaj: audio_hal.c. i pokazuje, jak są wysyłane zapytania o możliwości dla wielu urządzeń.

Weryfikacja

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

Testy CTS

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

Oto lista dostępnych testów Menedżera dźwięku:

  • AudioManagerTest#testGetDevices

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

  • AudioManagerTest#testPreferredDevicesForStrategy i AudioManagerTest#testPreferredDeviceForCapturePreset

    Sprawdź, czy preferowane urządzenia do strategii i nagrywania są powiązane Testy interfejsu API zostały ukończone.

Testy GTS

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

Aby sprawdzić, czy interfejsy API dla preferowanych urządzeń na potrzeby strategii i skonfigurowania gotowych ustawień przechwytywania działa prawidłowo, uruchom testy AudioServiceHostTest#testPreferredDeviceRouting i AudioServiceHostTest#testPreferredDeviceRoutingForCapturePreset.