La función Activador de sonido les brinda a las apps la capacidad de detectar ciertos eventos acústicos, como palabras clave, de manera eficiente en términos de energía y respetuosa de la privacidad. Algunos ejemplos de casos de uso de Activador de sonido son Asistente y Está sonando.
En esta página, se proporciona una descripción general de la arquitectura de Sound Trigger y su interfaz de HAL (capa de abstracción de hardware).
Pila de activadores de sonido
El subsistema del activador de sonido se compila en capas, como se muestra en la Figura 1:
Figura 1: Pila de activadores de sonido
En la siguiente lista, se describe con más detalle cada capa que se muestra en la Figura 1:
La capa de HAL (en verde) contiene el código específico del proveedor que implementa la interfaz HAL de activador de sonido (STHAL).
SoundTriggerMiddleware(en amarillo) reside sobre la interfaz de HAL. Se comunica con el HAL y es responsable de funciones como compartir el HAL entre diferentes clientes, registrar, aplicar permisos y controlar 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 la telefonía y los eventos de batería. También mantiene una base de datos de modelos de sonido, indexada por IDs únicos.Sobre la capa
SoundTriggerService, la pila (en marrón) controla las funciones específicas del Asistente y las apps genéricas por separado.
La función de la pila de activadores de sonido es entregar eventos discretos que representen eventos acústicos de activación. En la mayoría de los casos, la pila de activadores de sonido no se ocupa del audio. Cuando reciben los eventos del activador, las apps obtienen acceso a la transmisión de audio real, que rodea el momento de los eventos, abriendo un objeto AudioRecord a través del framework de audio. Las APIs de HAL de Sound Trigger proporcionan un identificador con el evento activado que se usa con el framework de audio. Por lo tanto, como el sistema HAL de activador de sonido y el sistema HAL de audio están conectados en segundo plano, suelen compartir un proceso.
Interfaz de la HAL de activador de sonido
La interfaz de HAL del activador de sonido (STHAL) es la parte específica del proveedor de la pila del activador de sonido y controla el reconocimiento de hardware de palabras clave 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 activador, envía un evento al framework y, luego, detiene la detección.
La interfaz STHAL se especifica en /hardware/interfaces/soundtrigger/.
La interfaz ISoundTriggerHw admite la capacidad de tener una o más sesiones de detección en ejecución en un momento determinado y de escuchar eventos acústicos.
Una llamada a ISoundTriggerHw.getProperties() muestra una estructura Properties que contiene la descripción y las capacidades de la implementación.
En la Figura 2, se explica el flujo básico para configurar una sesión de la siguiente manera:
Figura 2: Diagrama del estado de STHAL
En los siguientes pasos, se describe cada estado con más detalle:
El cliente HAL carga un modelo con
loadSoundModel()oloadPhraseSoundModel(). 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 a este algoritmo. Si se ejecutan correctamente, estos métodos muestran un control que se usa para hacer referencia a este modelo en llamadas posteriores.Una vez que se cargó correctamente el modelo, el cliente de HAL llama a
startRecognition()para comenzar la detección. El reconocimiento continúa ejecutándose en segundo plano hasta que se produce uno de los siguientes eventos:- Se llamó a un
stopRecognition()en este modelo. - Se produjo una detección.
- La detección se anula debido a restricciones de recursos, por ejemplo, cuando se inicia 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 registra el cliente de HAL cuando se carga. En todos los casos, después de alguno de estos eventos, la detección se vuelve inactiva y no se permiten más devoluciones de llamada de reconocimiento.
Se puede volver a iniciar el mismo modelo más adelante, y este proceso se puede repetir tantas veces como sea necesario.
- Se llamó a un
Por último, el cliente de HAL descarga un modelo inactivo que ya no se necesita a través de
unloadModel().
Cómo controlar errores de HAL
Para garantizar un comportamiento confiable y coherente entre las implementaciones de controladores, en Android 11, cualquier código de error que no se muestre correctamente desde el HAL se considera un error de programación, cuya recuperación requiere reiniciar el proceso de HAL. Esta es una estrategia de recuperación de último recurso, y se espera que esos casos no ocurran en un sistema que funcione correctamente.