Wyzwalacz dźwiękowy

Funkcja Sound Trigger zapewnia aplikacjom możliwość nasłuchiwania określonych zdarzeń akustycznych, takich jak słowa-klucze, przy niskim poborze mocy i zapewniającym prywatność. Przykładowe przypadki użycia Wyzwalacza dźwiękiem to Asystent i Teraz odtwarzane.

Na tej stronie znajduje się przegląd architektury Sound Trigger i jej interfejsu HAL (Hardware Abstraction Layer).

Stos wyzwalacza dźwięku

Podsystem Sound Trigger składa się z warstw, jak pokazano na rysunku 1:

Rysunek 1: Stos wyzwalacza dźwięku

Poniższa lista opisuje bardziej szczegółowo każdą warstwę pokazaną na rysunku 1:

• Warstwa HAL (na zielono) zawiera kod specyficzny dla dostawcy, który implementuje interfejs HAL (STHAL) wyzwalacza dźwięku .

  Uwaga: zaleca się bezpośrednią implementację interfejsu STHAL, a nie adapter wokół implementacji starszej warstwy HAL.

• SoundTriggerMiddleware (na żółto) znajduje się nad interfejsem HAL. Komunikuje się z warstwą HAL i odpowiada za takie funkcjonalności, jak udostępnianie warstwy HAL pomiędzy różnymi klientami, logowanie, egzekwowanie uprawnień i obsługa zgodności ze starszymi wersjami HAL.

• System SoundTriggerService (na niebiesko) znajduje się nad oprogramowaniem pośredniczącym. Ułatwia integrację z innymi funkcjami systemu, takimi jak zdarzenia telefonii i baterii. Prowadzi także bazę danych modeli dźwiękowych, indeksowanych według unikalnych identyfikatorów.

• Powyżej warstwy SoundTriggerService stos (w kolorze brązowym) obsługuje oddzielnie funkcje specyficzne dla Asystenta i aplikacji ogólnych.

Funkcją stosu Sound Trigger jest dostarczanie dyskretnych zdarzeń, które reprezentują zdarzenia akustyczne, wyzwalające. W większości przypadków stos wyzwalacza dźwięku nie obsługuje dźwięku. Po otrzymaniu zdarzeń wyzwalających aplikacje uzyskują dostęp do rzeczywistego strumienia audio otaczającego czas zdarzeń, otwierając obiekt AudioRecord za pośrednictwem środowiska Audio. Interfejsy API HAL wyzwalacza dźwięku zapewniają obsługę wyzwalanego zdarzenia używanego w środowisku audio. Dlatego też, ponieważ moduły Sound Trigger HAL i Audio HAL są połączone pod maską, zazwyczaj mają one wspólny proces.

Uwaga: ponieważ modele i typy danych są nieprzezroczyste dla struktury podsystemu Sound Trigger, oczekuje się, że aplikacje i implementacja HAL zachowują „ukrytą umowę”, to znaczy faktyczna zawartość, format i semantyka tych typów danych są uzgodnione od. Dlatego aplikacje korzystające z funkcji Sound Trigger powinny być dostarczane przez dostawców, a nie przez niezależnych programistów.

Interfejs HAL wyzwalania dźwiękiem

Interfejs Sound Trigger HAL (STHAL) jest specyficzną dla dostawcy częścią stosu Sound Trigger i obsługuje sprzętowe rozpoznawanie słów kluczowych i innych dźwięków. STHAL zapewnia jeden lub więcej silników, z których każdy działa na innym algorytmie zaprojektowanym do wykrywania określonej klasy dźwięków. Gdy STHAL wykryje wyzwalacz, wysyła zdarzenie do platformy, a następnie zatrzymuje wykrywanie.

Interfejs STHAL jest określony w /hardware/interfaces/soundtrigger/ .

Interfejs ISoundTriggerHw umożliwia uruchomienie jednej lub większej liczby sesji wykrywania w danym czasie i nasłuchiwanie zdarzeń akustycznych. Wywołanie metody ISoundTriggerHw.getProperties() zwraca strukturę Properties zawierającą opis implementacji i możliwości.

Podstawowy przebieg konfigurowania sesji wyjaśniono w następujący sposób na rysunku 2:

Rysunek 2: Diagram stanu STHAL

Poniższe kroki opisują każdy stan bardziej szczegółowo:

1. Klient HAL ładuje model za pomocą loadSoundModel() lub loadPhraseSoundModel() . Dostarczony obiekt modelu wskazuje, jakiego algorytmu wykrywania (silnika) specyficznego dla implementacji należy użyć, a także parametry mające zastosowanie dla tego algorytmu. W przypadku powodzenia metody te zwracają uchwyt, który służy do odwoływania się do tego modelu w kolejnych wywołaniach.

2. Po pomyślnym załadowaniu modelu klient HAL wywołuje startRecognition() , aby rozpocząć wykrywanie. Rozpoznawanie przebiega w tle do momentu wystąpienia jednego z następujących zdarzeń:

   1. W tym modelu wywołano funkcję stopRecognition() .
   2. Nastąpiło wykrycie.
   3. Wykrywanie zostaje przerwane ze względu na ograniczenia zasobów, na przykład po zainicjowaniu przypadku użycia o wyższym priorytecie.

   W dwóch ostatnich przypadkach zdarzenie rozpoznające jest wysyłane poprzez interfejs wywołania zwrotnego, który jest rejestrowany przez klienta HAL po załadowaniu. We wszystkich przypadkach, po wystąpieniu któregokolwiek z tych zdarzeń, wykrywanie staje się nieaktywne i nie są już dozwolone żadne wywołania zwrotne rozpoznawania.

   Ten sam model można uruchomić ponownie w późniejszym czasie, a proces ten można powtarzać tyle razy, ile potrzeba.

3. Na koniec nieaktywny model, który nie jest już potrzebny, jest rozładowywany przez klienta HAL za pomocą unloadModel() .

Uwaga: Po uruchomieniu modelu klient HAL może wywołać funkcję forceRecognitionEvent() w celu wygenerowania zdarzenia wymuszonego rozpoznania. Zwrócone zdarzenie jest podobne do normalnego zdarzenia rozpoznawania, ale jego pole statusu jest ustawione na FORCED . Takie zdarzenia rozpoznające nie powodują automatycznego zatrzymania rozpoznawania. Zamiast tego stan modelu pozostaje uruchomiony nawet po dostarczeniu zdarzenia.

Obsługa błędów HAL

Aby zapewnić niezawodne i spójne działanie pomiędzy implementacjami sterowników, w systemie Android 11 wszelkie kody błędów zakończone niepowodzeniem zwrócone z warstwy HAL są traktowane jako błędy programistyczne, których naprawa wymaga ponownego uruchomienia procesu HAL. Jest to strategia odzyskiwania ostateczności i oczekuje się, że takie przypadki nie będą miały miejsca w prawidłowo działającym systemie.

Uwaga: chociaż w dokumentacji interfejsu API HAL określa się te błędy jako prawidłowe, nie jest jasne, kiedy i w jakich stanach te kody błędów są zwracane oraz jaka jest oczekiwana procedura odzyskiwania po błędzie. Dlatego Android 11 wymaga bardziej rygorystycznej zgodności implementacji HAL Sound Trigger w czasie wykonywania niż starsze wersje Androida.