Sound Trigger

Funkcja wyzwalacza dźwięku umożliwia aplikacjom nasłuchiwanie określonych zdarzeń akustycznych, takich jak słowa aktywujące, w sposób energooszczędny i z poszanowaniem prywatności. Przykładowe przypadki użycia wyzwalacza dźwięku to Asystent i Teraz odtwarzane.

Na tej stronie znajdziesz ogólny opis architektury wyzwalacza dźwięku i jego interfejsu HAL (Hardware Abstraction Layer).

Stos Sound Trigger

Podsystem wyzwalania dźwiękiem jest zbudowany warstwowo, jak pokazano na rysunku 1:

sound_trigger_stack

Rysunek 1. Stos wyzwalacza dźwięku

Poniżej znajdziesz szczegółowy opis każdej warstwy przedstawionej na rysunku 1:

  • Warstwa HAL (na zielono) zawiera kod specyficzny dla dostawcy, który implementuje interfejs Sound Trigger HAL (STHAL).

  • SoundTriggerMiddleware (na żółto) znajduje się nad interfejsem HAL. Komunikuje się z HAL i odpowiada za funkcje takie jak udostępnianie HAL różnym klientom, rejestrowanie, 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 telefonia i zdarzenia związane z baterią. Utrzymuje też bazę danych modeli dźwięku indeksowanych według unikalnych identyfikatorów.

  • Nad warstwą SoundTriggerService stos (na brązowo) obsługuje funkcje specyficzne dla Asystenta i ogólnych aplikacji oddzielnie.

Funkcją stosu aktywatora dźwięku jest dostarczanie odrębnych zdarzeń, które reprezentują akustyczne zdarzenia aktywujące. W większości przypadków stos Sound Trigger nie przetwarza dźwięku. Po otrzymaniu zdarzeń wywołujących aplikacje uzyskują dostęp do rzeczywistego strumienia audio w okolicach czasu zdarzeń, otwierając obiekt AudioRecord za pomocą platformy Audio. Interfejsy API Sound Trigger HAL udostępniają uchwyt ze zdarzeniem wywołanym przez wyzwalacz dźwięku, który jest używany w ramach Audio Framework. Dlatego, że HAL wyzwalacza dźwięku i HAL dźwięku są ze sobą powiązane, zwykle działają w ramach tego samego procesu.

Interfejs HAL wyzwalacza dźwięku

Interfejs Sound Trigger HAL (STHAL) to część stosu Sound Trigger specyficzna dla dostawcy. Odpowiada on za rozpoznawanie sprzętowe słów kluczowych i innych dźwięków. STHAL udostępnia co najmniej jeden silnik, z których każdy korzysta z innego algorytmu zaprojektowanego 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 sekcji /hardware/interfaces/soundtrigger/.

Interfejs ISoundTriggerHw umożliwia prowadzenie co najmniej 1 sesji wykrywania w danym momencie i odsłuchiwanie zdarzeń akustycznych. Wywołanie funkcji ISoundTriggerHw.getProperties() zwraca strukturę Properties zawierającą opis implementacji i możliwości.

Podstawowy proces konfigurowania sesji przedstawiono na rysunku 2:

sthal_state

Ilustracja 2. Diagram stanu STHAL

Poniżej znajdziesz szczegółowe informacje o poszczególnych stanach:

  1. Klient HAL wczytuje model za pomocą loadSoundModel() lub loadPhraseSoundModel(). Podany obiekt modelu wskazuje, którego algorytmu wykrywania (silnika) specyficznego dla implementacji należy użyć, a także parametry mające zastosowanie w przypadku tego algorytmu. Jeśli operacja się uda, metody te zwracają uchwyt, który jest używany do odwoływania się do tego modelu w kolejnych wywołaniach.

  2. Po załadowaniu modelu klient HAL wywołuje funkcję startRecognition(), aby rozpocząć wykrywanie. Rozpoznawanie będzie działać w tle do momentu wystąpienia jednego z tych zdarzeń:

    1. W przypadku tego modelu zgłoszono stopRecognition().
    2. Wykryto zagrożenie.
    3. Wykrywanie zostało przerwane z powodu ograniczeń zasobów, np. gdy rozpoczęto przypadek użycia o wyższym priorytecie.

    W 2 ostatnich przypadkach zdarzenie rozpoznawania jest wysyłane za pomocą interfejsu wywołania zwrotnego zarejestrowanego przez klienta HAL podczas wczytywania. We wszystkich przypadkach po wystąpieniu któregokolwiek z tych zdarzeń wykrywanie staje się nieaktywne i nie są już dozwolone wywołania zwrotne rozpoznawania.

    Ten sam model można uruchomić ponownie w późniejszym czasie. Ten proces można powtarzać tyle razy, ile będzie to konieczne.

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

Obsługa błędów HAL

Aby zapewnić niezawodne i spójne działanie implementacji sterowników, w Androidzie 11 wszystkie kody błędów inne niż kody oznaczające powodzenie zwracane przez HAL są traktowane jako błędy programowania, których naprawienie wymaga ponownego uruchomienia procesu HAL. Jest to strategia odzyskiwania w ostateczności. Oczekuje się, że w prawidłowo działającym systemie takie przypadki nie będą się zdarzać.