La función Sound Trigger brinda a las aplicaciones la capacidad de escuchar ciertos eventos acústicos, como palabras activas, con bajo consumo de energía y respetando 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 (Hardware Abstraction Layer).
Pila de disparador de sonido
El subsistema Sound Trigger está construido en capas como se muestra en la Figura 1:
Figura 1: Pila de activación 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) se encuentra encima de la interfaz HAL. Se comunica con HAL y es responsable de funcionalidades como compartir HAL entre diferentes clientes, iniciar sesión, hacer cumplir permisos y manejar la compatibilidad con versiones anteriores de HAL.El sistema
SoundTriggerService(en azul) reside encima del 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 ID únicos.Por 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, que rodea el momento de los eventos, al abrir un objeto AudioRecord a través del marco de Audio. Las API HAL de Sound Trigger proporcionan un identificador del evento activado que se utiliza con Audio Framework. Por lo tanto, dado que Sound Trigger HAL y Audio HAL están conectados bajo el capó, normalmente comparten un proceso.
Interfaz HAL de disparo 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 clave 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 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 tener una o más sesiones de detección ejecutándose en un momento determinado y 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.
El flujo básico de configuración de una sesión se explica a continuación en la Figura 2:
Figura 2: diagrama de estado de STHAL
Los siguientes pasos describen cada estado con más detalle:
El cliente HAL carga un modelo usando
loadSoundModel()oloadPhraseSoundModel(). El objeto modelo proporcionado indica qué algoritmo (motor) de detección específico de la implementación utilizar, así como los parámetros aplicables para este algoritmo. Si tienen éxito, estos métodos devuelven un identificador que se utiliza para hacer referencia a este modelo en llamadas posteriores.Una vez que el modelo se ha cargado correctamente, el cliente HAL llama
startRecognition()para comenzar la detección. El reconocimiento continúa ejecutándose en segundo plano hasta que ocurre uno de los siguientes eventos:- Se ha llamado a
stopRecognition()en este modelo. - Se ha producido una detección.
- 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 registra el cliente HAL 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 más adelante y este proceso se puede repetir tantas veces como sea necesario.
- Se ha llamado a
Finalmente, el cliente HAL descarga un modelo inactivo que ya no es necesario mediante
unloadModel().
Manejar errores HAL
Para garantizar un comportamiento confiable y consistente entre las implementaciones de controladores, en Android 11, cualquier código de error no exitoso devuelto por HAL se trata como error de programación, cuya recuperación requiere reiniciar el proceso HAL. Esta es una estrategia de recuperación de último recurso y la expectativa es que tales casos no ocurran en un sistema que funcione correctamente.