Звуковой триггер

Функция Sound Trigger предоставляет приложениям возможность прослушивать определенные акустические события, например горячие слова, с низким энергопотреблением и с учетом конфиденциальности. Примеры использования Sound Trigger: Assistant и Now Playing.

На этой странице представлен обзор архитектуры Sound Trigger и его интерфейса HAL (Hardware Abstraction Layer).

Стек звуковых триггеров

Подсистема Sound Trigger построена слоями, как показано на рис. 1:

sound_trigger_stack

Рис. 1. Стек звуковых триггеров

В следующем списке более подробно описывается каждый слой, показанный на рис. 1:

  • Уровень HAL (зеленый) содержит код конкретного поставщика, который реализует интерфейс Sound Trigger HAL (STHAL).

  • Программное SoundTriggerMiddleware (выделено желтым цветом) находится над интерфейсом HAL. Он взаимодействует с HAL и отвечает за такие функции, как совместное использование HAL между разными клиентами, ведение журнала, применение разрешений и обеспечение совместимости со старыми версиями HAL.

  • Система SoundTriggerService (синяя) находится над промежуточным программным обеспечением. Это облегчает интеграцию с другими функциями системы, такими как телефония и события батареи. Он также поддерживает базу данных звуковых моделей, проиндексированных уникальными идентификаторами.

  • Над слоем SoundTriggerService стек (выделен коричневым цветом) отдельно обрабатывает функции, характерные для Assistant и общих приложений.

Функция стека звуковых триггеров заключается в доставке дискретных событий, которые представляют собой акустические триггерные события. В большинстве случаев стек Sound Trigger не работает со звуком. После получения событий триггера приложения получают доступ к фактическому аудиопотоку, окружающему время событий, путем открытия объекта AudioRecord через платформу Audio. HAL API-интерфейсы Sound Trigger предоставляют дескриптор инициированного события, которое используется с Audio Framework. Следовательно, поскольку звуковой триггер HAL и аудио HAL связаны внутри, они обычно используют один и тот же процесс.

Звуковой триггер HAL-интерфейс

Интерфейс Sound Trigger HAL (STHAL) является специфичной для поставщика частью стека Sound Trigger и обрабатывает аппаратное распознавание ключевых слов и других звуков. STHAL предоставляет один или несколько движков, каждый из которых использует свой алгоритм, предназначенный для обнаружения определенного класса звуков. Когда STHAL обнаруживает триггер, он отправляет событие в фреймворк, а затем останавливает обнаружение.

Интерфейс STHAL указан в /hardware/interfaces/soundtrigger/ .

Интерфейс ISoundTriggerHw поддерживает возможность запуска одного или нескольких сеансов обнаружения в заданное время и прослушивания акустических событий. Вызов ISoundTriggerHw.getProperties() возвращает структуру Properties , содержащую описание и возможности реализации.

Основной процесс настройки сеанса показан на рис. 2 следующим образом:

sthal_state

Рисунок 2: Диаграмма состояний STHAL

Следующие шаги описывают каждое состояние более подробно:

  1. Клиент HAL загружает модель с помощью loadSoundModel() или loadPhraseSoundModel() . Предоставленный объект модели указывает, какой алгоритм обнаружения (механизм) для конкретной реализации следует использовать, а также параметры, применимые для этого алгоритма. В случае успеха эти методы возвращают дескриптор, который используется для ссылки на эту модель при последующих вызовах.

  2. После успешной загрузки модели клиент HAL вызывает startRecognition() , чтобы начать обнаружение. Распознавание продолжает работать в фоновом режиме, пока не произойдет одно из следующих событий:

    1. Для этой модели была вызвана stopRecognition() .
    2. Произошло обнаружение.
    3. Обнаружение прерывается из-за нехватки ресурсов, например, когда был инициирован вариант использования с более высоким приоритетом.

    В последних двух случаях событие распознавания отправляется через интерфейс обратного вызова, который регистрируется клиентом HAL при загрузке. Во всех случаях после возникновения любого из этих событий обнаружение становится неактивным, и обратные вызовы распознавания больше не допускаются.

    Та же самая модель может быть запущена снова позже, и этот процесс может быть повторен столько раз, сколько необходимо.

  3. Наконец, неактивная модель, которая больше не нужна, выгружается клиентом HAL с помощью unloadModel() .

Обработка ошибок HAL

Чтобы обеспечить надежное и согласованное поведение между реализациями драйверов, в Android 11 любые неуспешные коды ошибок, возвращенные из HAL, рассматриваются как ошибки программирования, для устранения которых требуется перезапустить процесс HAL. Это крайняя стратегия восстановления, и ожидается, что такие случаи не возникнут в правильно работающей системе.