disparador de sonido

La función Sound Trigger brinda a las aplicaciones la capacidad de escuchar ciertos eventos acústicos, como hotwords, con bajo consumo de energía y de manera sensible a la privacidad. Ejemplos de casos de uso de Sound Trigger son Assistant y Now Playing.

Esta página ofrece una descripción general de la arquitectura Sound Trigger y su interfaz HAL (Capa de abstracción de hardware).

Pila de disparador de sonido

El subsistema Sound Trigger está construido en capas como se muestra en la Figura 1:

sound_trigger_stack

Figura 1: Pila de activadores de sonido

La siguiente lista describe cada capa que se muestra en la Figura 1 con más detalle:

  • La capa HAL (en verde) contiene el código específico del proveedor que implementa la interfaz Sound Trigger HAL (STHAL).

  • SoundTriggerMiddleware (en amarillo) reside sobre la interfaz HAL. Se comunica con HAL y es responsable de funcionalidades como compartir HAL entre diferentes clientes, iniciar sesión, aplicar permisos y manejar la compatibilidad con versiones anteriores de HAL.

  • El sistema SoundTriggerService (en azul) reside sobre el middleware. Facilita la integración con otras funciones del sistema, como telefonía y eventos de batería. También mantiene una base de datos de modelos de sonido, indexados por identificaciones únicas.

  • Encima de la capa SoundTriggerService , la pila (en marrón) maneja las funciones específicas del Asistente y las aplicaciones genéricas por separado.

La función de la pila Sound Trigger es entregar eventos discretos que representan eventos acústicos de activación. En la mayoría de los casos, la pila Sound Trigger no se ocupa del audio. Al recibir los eventos desencadenantes, las aplicaciones obtienen acceso a la transmisión de audio real, en torno a la hora de los eventos, al abrir un objeto AudioRecord a través del marco de audio. Las API de Sound Trigger HAL proporcionan un identificador con el evento activado que se utiliza con Audio Framework. Por lo tanto, dado que Sound Trigger HAL y Audio HAL están conectados debajo del capó, normalmente comparten un proceso.

Interfaz HAL de disparador de sonido

La interfaz Sound Trigger HAL (STHAL) es la parte específica del proveedor de la pila Sound Trigger y maneja el reconocimiento de hardware de palabras activas y otros sonidos. STHAL proporciona uno o más motores, cada uno de los cuales ejecuta un algoritmo diferente diseñado para detectar una clase específica de sonidos. Cuando STHAL detecta un disparador, envía un evento al marco y luego detiene la detección.

La interfaz STHAL se especifica en /hardware/interfaces/soundtrigger/ .

La interfaz ISoundTriggerHw admite la capacidad de ejecutar una o más sesiones de detección en un momento dado y escuchar eventos acústicos. Una llamada a ISoundTriggerHw.getProperties() devuelve una estructura de Properties que contiene la descripción y las capacidades de la implementación.

El flujo básico de configuración de una sesión se explica a continuación en la Figura 2:

sthal_state

Figura 2: diagrama de estado STHAL

Los siguientes pasos describen cada estado con más detalle:

  1. El cliente HAL carga un modelo usando loadSoundModel() o loadPhraseSoundModel() . El objeto de modelo proporcionado indica qué algoritmo de detección (motor) específico de la implementación se debe usar, así como los parámetros aplicables para este algoritmo. En caso de éxito, estos métodos devuelven un identificador que se utiliza para hacer referencia a este modelo en llamadas posteriores.

  2. Una vez que el modelo se ha cargado correctamente, el cliente HAL llama a startRecognition() para comenzar la detección. El reconocimiento continúa ejecutándose en segundo plano hasta que ocurre uno de los siguientes eventos:

    1. Se ha llamado a stopRecognition() en este modelo.
    2. Se ha producido una detección.
    3. La detección se cancela debido a limitaciones de recursos, por ejemplo, cuando se ha iniciado un caso de uso de mayor prioridad.

    En los dos últimos casos, se envía un evento de reconocimiento a través de la interfaz de devolución de llamada que el cliente HAL registra al cargar. En todos los casos, después de que ocurra cualquiera de estos eventos, la detección se vuelve inactiva y no se permiten más devoluciones de llamada de reconocimiento.

    El mismo modelo se puede volver a iniciar en un momento posterior, y este proceso se puede repetir tantas veces como sea necesario.

  3. Finalmente, el cliente HAL descarga un modelo inactivo que ya no se necesita a través unloadModel() .

Manejo de errores HAL

Para garantizar un comportamiento confiable y consistente entre las implementaciones de los controladores, en Android 11, cualquier código de error que no sea correcto devuelto por la HAL se trata como un error de programación, cuya recuperación requiere reiniciar el proceso de la HAL. Esta es una estrategia de recuperación de último recurso y se espera que tales casos no ocurran en un sistema que funcione correctamente.