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:

sound_trigger_stack

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 .

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

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:

sthal_state

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() .

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.