Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Disparador de sonido

La función Sound Trigger brinda a las aplicaciones la capacidad de escuchar ciertos eventos acústicos, como palabras clave, de una manera sensible a la privacidad y con bajo consumo de energía. Ejemplos de casos de uso de Sound Trigger son Asistente y Reproducción en curso.

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 disparadores de sonido

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

sound_trigger_stack

Figura 1: pila de sonido del disparador

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 el sonido del disparador HAL de interfaz (STHAL).

  • El SoundTriggerMiddleware (en amarillo) reside por encima de la interfaz de HAL. Se comunica con la HAL y es responsable de funcionalidades como compartir la HAL entre diferentes clientes, registrar, hacer cumplir los permisos y manejar la compatibilidad con versiones anteriores de HAL.

  • El SoundTriggerService (en azul) reside sistema por 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 SoundTriggerService capa, la pila (en marrón) manijas características específicas de Auxiliar y aplicaciones genéricas por separado.

La función de la pila Sound Trigger es entregar eventos discretos que representan eventos de activación acústicos. En la mayoría de los casos, la pila Sound Trigger no se ocupa del audio. Tras la recepción de los eventos de activación, las aplicaciones tienen acceso a la corriente de audio real, que rodea el momento de los hechos, mediante la apertura de una AudioRecord objeto a través del marco de audio. Las API de Sound Trigger HAL proporcionan un identificador con el evento desencadenado que se utiliza con Audio Framework. Por lo tanto, dado que Sound Trigger HAL y Audio HAL están conectados debajo del capó, generalmente comparten un proceso.

Interfaz Sound Trigger HAL

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 las 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/ .

El ISoundTriggerHw interfaz es compatible con la capacidad de tener uno o más sesiones de detección de marcha en un momento dado y para escuchar a los eventos acústicos. Una llamada a ISoundTriggerHw.getProperties() devuelve una Properties estructura que contiene la descripción y las capacidades de aplicación.

El flujo básico para configurar 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. Las cargas de los clientes HAL usando un modelo loadSoundModel() o loadPhraseSoundModel() . El objeto de modelo proporcionado indica qué algoritmo de detección específico de implementación (motor) utilizar, así como los parámetros aplicables para este algoritmo. Tras el é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 ha sido cargado con éxito, el cliente llama a HAL startRecognition() para iniciar la detección. El reconocimiento continúa ejecutándose en segundo plano hasta que ocurre uno de los siguientes eventos:

    1. Un stopRecognition() se ha llamado 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 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 iniciar de nuevo más tarde y este proceso se puede repetir tantas veces como sea necesario.

  3. Por último, un modelo inactivo que ya no se necesita es descargado por el cliente a través de HAL unloadModel() .

Manejo de errores HAL

Para garantizar un comportamiento confiable y consistente entre las implementaciones de controladores, en Android 11, cualquier código de error que no sea exitoso devuelto por HAL se trata como errores 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.