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

Функция «Звуковой триггер» позволяет приложениям отслеживать определенные акустические события, например, ключевые слова, с низким энергопотреблением и с учетом требований конфиденциальности. Примерами использования функции «Звуковой триггер» являются Google Assistant и приложение «Сейчас воспроизводится».

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

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

Подсистема звукового триггера построена послойно, как показано на рисунке 1:

sound_trigger_stack

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

Ниже представлен более подробный список каждого слоя, показанного на рисунке 1:

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

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

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

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

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

Интерфейс Sound Trigger 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. Это стратегия восстановления в крайнем случае, и предполагается, что такие случаи не будут возникать в корректно работающей системе.