Sound Trigger

Funkcja Sound Trigger umożliwia aplikacjom nasłuchiwanie określonych zdarzeń akustycznych, takich jak słowa aktywujące, w sposób energooszczędny i z zachowaniem prywatności. Przykłady zastosowań funkcji Sound Trigger to Asystent i Co jest grane.

Na tej stronie znajdziesz ogólne informacje o architekturze funkcji Sound Trigger i jej interfejsie HAL (warstwa abstrakcji sprzętowej).

Stos Sound Trigger

Podsystem Sound Trigger jest zbudowany warstwowo, jak pokazano na rysunku 1:

sound_trigger_stack

Rysunek 1: stos Sound Trigger

Poniższa lista zawiera szczegółowy opis każdej warstwy pokazanej na rysunku 1:

  • The 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 interfejsem HAL i odpowiada za funkcje takie jak udostępnianie interfejsu HAL różnym klientom, logowanie, egzekwowanie uprawnień i obsługę zgodności ze starszymi wersjami interfejsu 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) oddzielnie obsługuje funkcje specyficzne dla Asystenta i ogólnych aplikacji.

Funkcją stosu Sound Trigger jest dostarczanie dyskretnych zdarzeń reprezentujących zdarzenia akustyczne i wyzwalające. W większości przypadków stos Sound Trigger nie ma do czynienia z dźwiękiem. Po otrzymaniu zdarzeń wyzwalających aplikacje uzyskują dostęp do rzeczywistego strumienia audio otaczającego czas zdarzeń, otwierając obiekt AudioRecord za pomocą platformy Audio. Interfejsy API Sound Trigger HAL udostępniają uchwyt ze zdarzeniem wyzwalającym, który jest używany z platformą Audio. Dlatego, ponieważ interfejs Sound Trigger HAL i interfejs Audio HAL są połączone pod maską, zwykle współdzielą proces.

Interfejs Sound Trigger HAL

Interfejs Sound Trigger HAL (STHAL) jest częścią stosu Sound Trigger specyficzną dla dostawcy i obsługuje sprzętowe rozpoznawanie słów aktywujących i innych dźwięków. STHAL udostępnia co najmniej 1 silnik, z których każdy uruchamia inny algorytm zaprojektowany 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 katalogu /hardware/interfaces/soundtrigger/.

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

Podstawowy proces konfigurowania sesji jest opisany na rysunku 2:

sthal_state

Rysunek 2: diagram stanu STHAL

Poniższe kroki zawierają szczegółowy opis każdego stanu:

  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ć, oraz parametry mające zastosowanie do tego algorytmu. Jeśli operacja się powiedzie, te metody zwracają uchwyt, który jest używany do odwoływania się do tego modelu w kolejnych wywołaniach.

  2. Gdy model zostanie wczytany, klient HAL wywołuje startRecognition(), aby rozpocząć wykrywanie. Rozpoznawanie jest kontynuowane w tle do momentu wystąpienia jednego z tych zdarzeń:

    1. Dla tego modelu wywołano stopRecognition().
    2. Wykryto wyzwalacz.
    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 przez interfejs wywołania zwrotnego zarejestrowany 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 żadne wywołania zwrotne rozpoznawania.

    Ten sam model można ponownie uruchomić w późniejszym czasie, a ten proces można powtarzać dowolną liczbę razy.

  3. Na koniec nieaktywny model, który nie jest już potrzebny, jest zwalniany przez klienta HAL za pomocą 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 powodzenia zwracane przez interfejs HAL są traktowane jako błędy programowania, których naprawienie wymaga ponownego uruchomienia procesu HAL. Jest to strategia naprawy ostatniej szansy i oczekuje się, że takie przypadki nie będą występować w prawidłowo działającym systemie.