Łączenie routingu 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 podwyższonymi uprawnieniami mogą wybieranie wielu preferowanych urządzeń na potrzeby konkretnej strategii. za pomocą systemowych interfejsów API. 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 ramy 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.

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. Przekierowywanie do wielu urządzeń USB jednocześnie nie jest obsługiwane.

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 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ę:

  • 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 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 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. 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.

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 urządzenia połączone lub odłączone. Menedżer zasad dotyczących dźwięku używa do wyboru aktywnych urządzeń multimedialnych tej serii reguł:

  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.

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

Aby zastosować wybrane nowe urządzenie, Menedżer zasad dotyczących dźwięku zamyka się i 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 dźwięku udostępnia tę listę interfejsów API systemu (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 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 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

    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. 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, 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 HAL dźwięku

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

  • 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. 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 opisaliśmy kilka zestawów testów zawierających metody korzystające z interfejsów API omawianych w poprzednich sekcjach. Oto kilka przykładów tych metod jak implementować i używać 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.

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

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

    Sprawdza 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 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.