La función Activador de sonido proporciona a las apps la capacidad de escuchar ciertos eventos acústicos, como palabras clave activadoras, de una manera que ahorra energía y respeta la privacidad. Algunos ejemplos de casos de uso de Sound Trigger son Asistente y la función En reproducción.
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 Sound Trigger
El subsistema de activador de sonido se compila en capas, como se muestra en la Figura 1:
Figura 1: Pila de activador de sonido
En la siguiente lista, se describe cada capa que se muestra en la figura 1 con más detalle:
La capa de HAL (en verde) contiene el código específico del proveedor que implementa la interfaz de la HAL de Sound Trigger (STHAL).
SoundTriggerMiddleware(en amarillo) se encuentra sobre la interfaz de HAL. Se comunica con el HAL y es responsable de funcionalidades como compartir el HAL entre diferentes clientes, registrar, aplicar permisos y controlar la compatibilidad con versiones anteriores del HAL.El sistema
SoundTriggerService(en azul) se encuentra sobre el middleware. Facilita la integración con otras funciones del sistema, como eventos de telefonía y batería. También mantiene una base de datos de modelos de sonido, indexados por IDs únicos.Por encima de la capa de
SoundTriggerService, la pila (en marrón) controla las funciones específicas de Assistant y las apps genéricas por separado.
La función de la pila de Sound Trigger es entregar eventos discretos que representan eventos acústicos de activación. En la mayoría de los casos, la pila de Sound Trigger no procesa audio. Cuando se reciben los eventos de activación, las apps obtienen acceso al flujo de audio real que rodea el momento de los eventos. Para ello, abren un objeto AudioRecord a través del marco de trabajo de Audio. Las APIs del HAL de Sound Trigger proporcionan un identificador con el evento activado que se usa con Audio Framework. Por lo tanto, dado que el HAL de Sound Trigger y el HAL de Audio están conectados de forma interna, suelen compartir un proceso.
Interfaz de la HAL de Sound Trigger
La interfaz de HAL de Sound Trigger (STHAL) es la parte específica del proveedor de la pila de Sound Trigger y controla el reconocimiento de hardware de palabras clave activas y otros sonidos. STHAL proporciona uno o más motores, y cada uno 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 de 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() devuelve 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 de estado de STHAL
En los siguientes pasos, se describe cada estado con más detalle:
El cliente de HAL carga un modelo con
loadSoundModel()oloadPhraseSoundModel(). El objeto del 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. Si se ejecutan correctamente, estos métodos devuelven un identificador que se usa para hacer referencia a este modelo en llamadas posteriores.Una vez que el modelo se cargó correctamente, el cliente HAL llama a
startRecognition()para comenzar la detección. El reconocimiento sigue ejecutándose en segundo plano hasta que ocurre 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 limitaciones de recursos, por ejemplo, cuando se inició 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 del HAL durante la carga. En todos los casos, después de que ocurra cualquiera de estos eventos, la detección se desactivará y no se permitirán más devoluciones de llamada de reconocimiento.
El mismo modelo se puede iniciar de nuevo en otro momento, 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, todos los códigos de error que no sean de éxito que se devuelvan desde el HAL se tratan como errores de programación, cuya recuperación requiere reiniciar el proceso del HAL. Esta es una estrategia de recuperación de último recurso, y se espera que estos casos no ocurran en un sistema que funcione correctamente.