Activación por voz

  • Artículo

Nota

Este tema hace referencia principalmente a nuestras experiencias de consumidor, que se entregan actualmente en Windows 10 (versión 1909 y anteriores) Para obtener más información, vea Fin de soporte técnico de Cortana en Windows y Teams.

Cortana, la tecnología de asistente personal se demostró por primera vez en la Conferencia para desarrolladores de Microsoft BUILD en 2013. La plataforma de voz de Windows se usa para potenciar todas las experiencias de voz en Windows 10 como Cortana y Dictado. La activación por voz es una característica que permite a los usuarios invocar un motor de reconocimiento de voz desde varios estados de energía del dispositivo diciendo una frase específica: "Hola Cortana". Para crear hardware que admita la tecnología de activación de voz, revise la información de este tema.

Nota

La implementación de la activación por voz es un proyecto importante y es una tarea completada por los proveedores de SoC. Los OEM pueden ponerse en contacto con su proveedor de SoC para obtener información sobre la implementación de soC de activación por voz.

Experiencia del usuario final de Cortana

Para comprender la experiencia de interacción de voz disponible en Windows, revise estos temas.

Tema Descripción
¿Qué es Cortana? Proporciona información general y dirección de uso para Cortana

Introducción a la activación de voz "Hola Cortana" y "Aprender mi voz"

Hola Cortana" Activación por voz

La característica "Hola Cortana" de activación por voz (VA) permite a los usuarios interactuar rápidamente con la experiencia de Cortana fuera de su contexto activo (es decir, lo que está actualmente en pantalla) mediante su voz. A menudo, los usuarios quieren poder acceder al instante a una experiencia sin tener que interactuar físicamente con un dispositivo. Para los usuarios telefónicos esto puede deberse a la conducción en el coche y tener su atención y manos comprometidas con el funcionamiento del vehículo. Para un usuario de Xbox, esto puede deberse a que no desea buscar y conectar un controlador. En el caso de los usuarios del equipo, esto puede deberse a un acceso rápido a una experiencia sin tener que realizar varias acciones de mouse, táctil o teclado, por ejemplo, un ordenador en la cocina.

La activación por voz proporciona siempre escuchando la entrada de voz a través de frases clave predefinidas o "frases de activación". Las frases clave pueden ser expresiones por sí mismas ("Hey Cortana") como un comando preconfigurado o seguidas de una acción de voz, por ejemplo, "Hey Cortana, donde es mi próxima reunión?", un comando encadenado.

El término Detección de palabras clave, describe la detección de la palabra clave por hardware o software.

La activación solo de palabra clave se produce cuando solo se dice la palabra clave Cortana, Cortana inicia y reproduce el sonido EarCon para indicar que ha entrado en modo de escucha.

Un comando encadenado describe la capacidad de emitir un comando inmediatamente después de la palabra clave (como "Hola Cortana, llamar a John") y hacer que Cortana se inicie (si aún no se ha iniciado) y siga el comando (iniciando una llamada telefónica con John).

En este diagrama se muestra la activación solo encadenada y de palabra clave.

Diagrama que muestra la diferencia entre la activación encadenada y solo de palabra clave con el búfer de audio y la secuencia de tiempo.

Microsoft proporciona un spotter de palabras clave predeterminado del sistema operativo (spotter de palabras clave de software) que se usa para garantizar la calidad de las detecciones de palabras clave de hardware y para proporcionar la experiencia Hey Cortana en los casos en los que la detección de palabras clave de hardware no está presente o no está disponible.

La característica "Aprender mi voz"

La característica "Aprender mi voz" permite al usuario entrenar a Cortana para reconocer su voz única. Para ello, el usuario selecciona Aprender cómo digo "Hola Cortana" en la pantalla de configuración de Cortana. A continuación, el usuario repite seis frases cuidadosamente elegidas que proporcionan una variedad suficiente de patrones fonéticos para identificar los atributos únicos de la voz de los usuarios.

Captura de pantalla de la configuración de escritorio de Cortana para el spotter de palabra clave de hardware y reactivación en la característica de voz.

Cuando la activación por voz está emparejada con "Learn my voice", los dos algoritmos funcionarán juntos para reducir las activaciones falsas. Esto es especialmente valioso para el escenario de la sala de reuniones, donde una persona dice "Hola Cortana" en una sala llena de dispositivos. Esta característica solo está disponible para Windows 10 versión 1903 y anteriores.

La activación por voz se basa en un spotter de palabras clave (KWS) que reacciona si se detecta la frase clave. Si el KWS es reactivar el dispositivo desde un estado de baja potencia, la solución se conoce como Wake on Voice (WoV). Para obtener más información, consulte Wake on Voice.

Glosario de términos

En este glosario se resumen los términos relacionados con la activación por voz.

Término Ejemplo y definición
Comando preconfigurado Ejemplo: Hola Cortana <pausa, espere el earcon> ¿Cuál es el tiempo? Esto se conoce a veces como "Comando de dos disparos" o "Solo palabra clave"
Comando encadenado Ejemplo: ¿Qué hace Cortana? Esto se conoce a veces como un "comando de un solo disparo"
Activación por voz Escenario de proporcionar la detección de palabras clave de una frase de clave de activación predefinida. Por ejemplo, "Hola Cortana" es el escenario de activación por voz de Microsoft.
WoV Wake-on-Voice: tecnología que permite la activación por voz desde una pantalla apagada, un estado de energía inferior, a una pantalla en estado de alimentación completa.
WoV desde el modo de espera moderno Wake-on-Voice desde un estado De espera moderno (S0ix) a una pantalla en estado de alimentación completa (S0).
Modo de espera moderno Infraestructura inactiva de bajo consumo de Windows: sucesora de Connected Standby (CS) en Windows 10. El primer estado de espera moderno es cuando la pantalla está desactivada. El estado de suspensión más profundo es cuando se encuentra en DRIPS/Resistencia. Para obtener más información, consulte Modern Standby (Modo de espera moderno).
KWS Spotter de palabras clave: el algoritmo que proporciona la detección de "Hey Cortana"
SW KWS Spotter de palabras clave de software: una implementación de KWS que se ejecuta en el host (CPU). Para "Hola Cortana", SW KWS se incluye como parte de Windows.
HW KWS Spotter de palabra clave descargado por hardware: una implementación de KWS que se ejecuta descargado en hardware.
Búfer de ráfaga Un búfer circular utilizado para almacenar datos pcM que se pueden "expandir" en caso de una detección de KWS, de modo que se incluya todo el audio que desencadenó una detección de KWS.
Adaptador oem del detector de palabras clave Corrección de compatibilidad de nivel de controlador que permite que el HW habilitado para WoV se comunique con Windows y la pila de Cortana.
Modelo El archivo de datos del modelo acústico utilizado por el algoritmo KWS. El archivo de datos es estático. Los modelos se localizan, uno por configuración regional.

Integración de un spotter de palabra clave de hardware

Para implementar un spotter de palabra clave de hardware (HW KWS), los proveedores de SoC deben completar las siguientes tareas.

Requisitos de WoV para el spotter de palabras clave descargados por hardware (HW KWS)

  • HW KWS WoV se admite durante el estado de trabajo S0 y el estado de suspensión S0 también conocido como Modern Standby.
  • HW KWS WoV no es compatible con S3.

Requisitos de AEC para HW KWS

  • Para Windows versión 1709

    • Para admitir HW KWS WoV para el estado de suspensión S0 (modern standby) AEC no es necesario.
    • HW KWS WoV for S0 working state is not supported in Windows Version 1709.

  • Para Windows versión 1803

    • Se admite HW KWS WoV para el estado de trabajo S0.
    • Para habilitar HW KWS WoV para el estado de trabajo S0, el APO debe admitir AEC.

Introducción al código de ejemplo

Hay código de ejemplo para un controlador de audio que implementa la activación por voz en GitHub como parte del ejemplo de adaptador de audio virtual SYSVAD. Se recomienda usar este código como punto de partida. El código está disponible en esta ubicación.

https://github.com/Microsoft/Windows-driver-samples/tree/main/audio/sysvad/

Para obtener más información sobre el controlador de audio de ejemplo SYSVAD, vea Controladores de audio de ejemplo.

Información del sistema de reconocimiento de palabras clave

Compatibilidad con la pila de audio de activación de voz

Las interfaces externas de pila de audio para habilitar la activación por voz sirven como canalización de comunicación para la plataforma de voz y los controladores de audio. Las interfaces externas se dividen en tres partes.

  • Interfaz del controlador de dispositivo (DDI) del detector de palabras clave. El detector de palabras clave Device Driver Interface es responsable de configurar y armar el spotter de palabras clave HW (KWS). También lo usa el controlador para notificar al sistema un evento de detección.
  • DLL del adaptador de OEM del detector de palabras clave. Este archivo DLL implementa una interfaz COM para adaptar los datos opacos específicos del controlador para que los use el sistema operativo para ayudar con la detección de palabras clave.
  • Mejoras de streaming de WaveRT. Las mejoras permiten al controlador de audio expandir los datos de audio almacenados en búfer de la detección de palabras clave.

Propiedades del punto de conexión de audio

La creación de grafos de punto de conexión de audio se produce normalmente. El gráfico está preparado para controlar la captura en tiempo real más rápido. Las marcas de tiempo en los búferes capturados siguen siendo verdaderas. En concreto, las marcas de tiempo reflejarán correctamente los datos capturados en el pasado y almacenados en búfer, y ahora es "ráfaga".

Teoría del streaming de audio de omisión de Bluetooth

El controlador expone un filtro KS para su dispositivo de captura como de costumbre. Este filtro admite varias propiedades KS y un evento KS para configurar, habilitar y señalar un evento de detección. El filtro también incluye un generador de patillas adicional identificado como un pin de palabra clave (KWS). Este pin se usa para transmitir audio desde el spotter de palabra clave.

Las propiedades son las siguientes:

  • Tipos de palabras clave admitidos : KSPROPERTY_SOUNDDETECTOR_PATTERNS. El sistema operativo establece esta propiedad para configurar las palabras clave que se van a detectar.
  • Lista de GUID de patrones de palabra clave: KSPROPERTY_SOUNDDETECTOR_SUPPORTEDPATTERNS. Esta propiedad se usa para obtener una lista de GUID que identifican los tipos de patrones admitidos.
  • Armado - KSPROPERTY_SOUNDDETECTOR_ARMED. Esta propiedad de lectura y escritura es simplemente un estado booleano que indica si el detector está armado. El sistema operativo establece esto para que interactúe con el detector de palabras clave. El sistema operativo puede borrar esto para desasociar. El controlador borra esto automáticamente cuando se establecen patrones de palabra clave y también después de detectar una palabra clave. (El sistema operativo debe rediseñarse).
  • Resultado de coincidencia: KSPROPERTY_SOUNDDETECTOR_MATCHRESULT. Esta propiedad de lectura contiene los datos de resultado después de que se haya producido la detección.

El evento que se desencadena cuando se detecta una palabra clave es un evento KSEVENT_SOUNDDETECTOR_MATCHDETECTED .

Secuencia de operación

Inicio del sistema

  1. El sistema operativo lee los tipos de palabras clave admitidos para comprobar que tiene palabras clave en ese formato.
  2. El sistema operativo se registra para el evento de cambio de estado del detector.
  3. El sistema operativo establece los patrones de palabra clave.
  4. El sistema operativo arma el detector.

Al recibir el evento KS

  1. El controlador desarme el detector.
  2. El sistema operativo lee el estado del detector de palabras clave, analiza los datos devueltos y determina qué patrón se detectó.
  3. El sistema operativo rediseña el detector.

Controlador interno y operación de hardware

Mientras el detector está armado, el hardware puede capturar y almacenar en búfer continuamente datos de audio en un pequeño búfer FIFO. (El tamaño de este búfer FIFO viene determinado por los requisitos fuera de este documento, pero normalmente puede ser de cientos de milisegundos a varios segundos). El algoritmo de detección funciona en el streaming de datos a través de este búfer. El diseño del controlador y el hardware son tales que, mientras que armado no hay interacción entre el controlador y el hardware y no hay interrupciones en los procesadores de "aplicación" hasta que se detecta una palabra clave. Esto permite al sistema alcanzar un estado de energía inferior si no hay ninguna otra actividad.

Cuando el hardware detecta una palabra clave, genera una interrupción. Mientras espera a que el controlador service la interrupción, el hardware continúa capturando audio en el búfer, lo que garantiza que no se pierdan datos después de que se pierda la palabra clave, dentro de los límites de almacenamiento en búfer.

Marcas de tiempo de palabra clave

Después de detectar una palabra clave, todas las soluciones de activación de voz deben almacenar en búfer toda la palabra clave hablada, incluidas las 250 ms antes del inicio de la palabra clave. El controlador de audio debe proporcionar marcas de tiempo que identifiquen el inicio y el final de la frase clave en la secuencia.

Para admitir las marcas de tiempo inicial y final de la palabra clave, el software DSP puede necesitar eventos de marca de tiempo internamente basados en un reloj DSP. Una vez detectada una palabra clave, el software DSP interactúa con el controlador para preparar un evento KS. El controlador y el software DSP deberán asignar las marcas de tiempo de DSP a un valor de contador de rendimiento de Windows. El método de hacer esto es específico del diseño de hardware. Una posible solución es que el controlador lea el contador de rendimiento actual, consulte la marca de tiempo de DSP actual, vuelva a leer el contador de rendimiento actual y, a continuación, calcule una correlación entre el contador de rendimiento y el tiempo de DSP. A continuación, dada la correlación, el controlador puede asignar las marcas de tiempo de DSP de la palabra clave a las marcas de tiempo del contador de rendimiento de Windows.

Interfaz del adaptador oem del detector de palabras clave

El OEM proporciona una implementación de objeto COM que actúa como intermediario entre el sistema operativo y el controlador, lo que ayuda a calcular o analizar los datos opacos que se escriben y leen en el controlador de audio a través de KSPROPERTY_SOUNDDETECTOR_PATTERNS y KSPROPERTY_SOUNDDETECTOR_MATCHRESULT.

El CLSID del objeto COM es un GUID de tipo de patrón de detector devuelto por el KSPROPERTY_SOUNDDETECTOR_SUPPORTEDPATTERNS. El sistema operativo llama a CoCreateInstance pasando el GUID de tipo de patrón para crear una instancia del objeto COM adecuado compatible con el tipo de patrón de palabra clave y llama a métodos en la interfaz IKeywordDetectorOemAdapter del objeto.

Requisitos del modelo de subprocesos COM

La implementación del OEM puede elegir cualquiera de los modelos de subprocesos COM.

IKeywordDetectorOemAdapter

El diseño de la interfaz intenta mantener la implementación de objetos sin estado. Es decir, la implementación no debe requerir que se almacene ningún estado entre llamadas de método. De hecho, es probable que las clases internas de C++ no necesiten ninguna variable miembro más allá de las necesarias para implementar un objeto COM en general.

Métodos

Implemente los métodos siguientes.

KEYWORDID

La enumeración KEYWORDID identifica el texto o función de frase de una palabra clave y también se usa en los adaptadores del servicio biométrico de Windows. Para obtener más información, consulte Información general sobre el marco biométrico: componentes principales de la plataforma.

typedef enum  {
  KwInvalid              = 0,
  KwHeyCortana           = 1,
  KwSelect               = 2
} KEYWORDID;

KEYWORDSELECTOR

La estructura KEYWORDSELECTOR es un conjunto de identificadores que seleccionan de forma única una palabra clave y un lenguaje concretos.

typedef struct
{
    KEYWORDID KeywordId;
    LANGID LangId;
} KEYWORDSELECTOR;

Control de datos del modelo

Modelo independiente del usuario estático : el archivo DLL de OEM normalmente incluiría algunos datos estáticos del modelo independiente del usuario integrados en el archivo DLL o en un archivo de datos independiente incluido con el archivo DLL. El conjunto de identificadores de palabra clave admitidos devueltos por la rutina GetCapabilities dependerá de estos datos. Por ejemplo, si la lista de identificadores de palabra clave admitidos devueltos por GetCapabilities incluye KwHeyCortana, los datos estáticos del modelo independiente del usuario incluirían datos para "Hey Cortana" (o su traducción) para todos los idiomas admitidos.

Modelo dependiente del usuario dinámico : IStream proporciona un modelo de almacenamiento de acceso aleatorio. El sistema operativo pasa un puntero de interfaz IStream a muchos de los métodos de la interfaz IKeywordDetectorOemAdapter. El sistema operativo realiza una copia de seguridad de la implementación de IStream con el almacenamiento adecuado para hasta 1 MB de datos.

El OEM define el contenido y la estructura de los datos dentro de este almacenamiento. El propósito previsto es para el almacenamiento persistente de los datos del modelo dependientes del usuario calculados o recuperados por el ARCHIVO DLL de OEM.

El sistema operativo puede llamar a los métodos de interfaz con un IStream vacío, especialmente si el usuario nunca ha entrenado una palabra clave. El sistema operativo crea un almacenamiento IStream independiente para cada usuario. En otras palabras, un IStream determinado almacena los datos del modelo para uno y solo un usuario.

El desarrollador de ARCHIVOS DLL de OEM decide cómo administrar los datos independientes del usuario y dependientes del usuario. Sin embargo, nunca almacenará datos de usuario fuera de IStream. Un posible diseño de DLL de OEM cambiaría internamente entre el acceso a IStream y los datos independientes del usuario estático en función de los parámetros del método actual. Un diseño alternativo podría comprobar el IStream al principio de cada llamada de método y agregar los datos independientes del usuario estático a IStream si aún no está presente, lo que permite que el resto del método tenga acceso solo a IStream para todos los datos del modelo.

Procesamiento de audio de entrenamiento y operación

Como se ha descrito anteriormente, el flujo de la interfaz de usuario de entrenamiento da como resultado oraciones totalmente enriquecidas fonéticamente disponibles en la secuencia de audio. Cada frase se pasa individualmente a IKeywordDetectorOemAdapter::VerifyUserKeyword para comprobar que contiene la palabra clave esperada y tiene una calidad aceptable. Una vez recopiladas y comprobadas todas las oraciones por la interfaz de usuario, todas se pasan en una llamada a IKeywordDetectorOemAdapter::ComputeAndAddUserModelData.

El audio se procesa de forma única para el entrenamiento de activación por voz. En la tabla siguiente se resumen las diferencias entre el entrenamiento de activación de voz y el uso normal del reconocimiento de voz.

|

Entrenamiento de voz Reconocimiento de voz
Modo Raw Sin formato o voz
Anclar Normal KWS
Formato de audio Float de 32 bits (Tipo = Audio, Subtipo = IEEE_FLOAT, Frecuencia de muestreo = 16 kHz, bits = 32) Administrado por la pila de audio del sistema operativo
Mic Micrófono 0 Todos los micrófonos de la matriz o mono

Introducción al sistema de reconocimiento de palabras clave

En este diagrama se proporciona información general sobre el sistema de reconocimiento de palabras clave.

Diagrama del sistema de reconocimiento de palabras clave, incluidos los componentes de Cortana, tiempo de ejecución de voz y administrador de activación de voz.

Diagramas de secuencia de reconocimiento de palabras clave

En estos diagramas, el módulo de tiempo de ejecución de voz se muestra como la "plataforma de voz". Como se mencionó anteriormente, la plataforma de voz de Windows se usa para potenciar todas las experiencias de voz en Windows 10 como Cortana y dictado.

Durante el inicio, las funcionalidades se recopilan mediante IKeywordDetectorOemAdapter::GetCapabilities.

Diagrama de secuencia del reconocimiento de palabras clave durante el inicio, que muestra la experiencia de usuario de entrenamiento, la plataforma de voz y el detector de palabras clave OEM.

Más adelante, cuando el usuario selecciona "Learn my voice", se invoca el flujo de entrenamiento.

Diagrama de secuencia del reconocimiento de palabras clave durante el proceso

En este diagrama se describe el proceso de arming para la detección de palabras clave.

Diagrama de secuencia del reconocimiento de palabras clave durante el arming para la detección de palabras clave, que muestra la plataforma de voz, el detector de palabras clave OEM y el detector de unidades de audio.

Mejoras de WAVERT

Las interfaces de minipuerto se definen para ser implementadas por los controladores de miniporte de WaveRT. Estas interfaces proporcionan métodos para simplificar el controlador de audio, mejorar el rendimiento y la confiabilidad de la canalización de audio del sistema operativo, o admitir nuevos escenarios. Se define una nueva propiedad de interfaz de dispositivo PnP, lo que permite al controlador proporcionar expresiones estáticas de sus restricciones de tamaño de búfer al sistema operativo.

Tamaños de búfer

Un controlador funciona bajo varias restricciones al mover datos de audio entre el sistema operativo, el controlador y el hardware. Estas restricciones pueden deberse al transporte de hardware físico que mueve datos entre la memoria y el hardware, o debido a los módulos de procesamiento de señal dentro del hardware o DSP asociado.

Las soluciones HW-KWS deben admitir tamaños de captura de audio de al menos 100 ms y hasta 200 ms.

El controlador expresa las restricciones de tamaño del búfer estableciendo la propiedad DEVPKEY_KsAudio_PacketSize_Constraints dispositivo en la interfaz de dispositivo PnP de KSCATEGORY_AUDIO del filtro KS que tiene los pin(s) de streaming de KS. Esta propiedad debe permanecer válida y estable mientras la interfaz de filtro KS está habilitada. El sistema operativo puede leer este valor en cualquier momento sin tener que abrir un identificador al controlador y llamar a en el controlador.

DEVPKEY_KsAudio_PacketSize_Constraints

El valor de la propiedad DEVPKEY_KsAudio_PacketSize_Constraints contiene una estructura de KSAUDIO_PACKETSIZE_CONSTRAINTS que describe las restricciones de hardware físicos (es decir, debido a la mecánica de transferir datos del búfer de WaveRT al hardware de audio). La estructura incluye una matriz de 0 o más estructuras KSAUDIO_PACKETSIZE_PROCESSINGMODE_CONSTRAINT que describen restricciones específicas de cualquier modo de procesamiento de señal. El controlador establece esta propiedad antes de llamar a PcRegisterSubdevice o habilitar su interfaz de filtro KS para sus patillas de streaming.

IMiniportWaveRTInputStream

Un controlador implementa esta interfaz para una mejor coordinación del flujo de datos de audio del controlador al sistema operativo. Si esta interfaz está disponible en una secuencia de captura, el sistema operativo usa métodos en esta interfaz para acceder a los datos del búfer de WaveRT. Para obtener más información, vea IMiniportWaveRTInputStream::GetReadPacket.

IMiniportWaveRTOutputStream

Una miniporte waveRT implementa opcionalmente esta interfaz para que se le recomiende el progreso de escritura desde el sistema operativo y para devolver la posición precisa del flujo. Para obtener más información, vea IMiniportWaveRTOutputStream::SetWritePacket, IMiniportWaveRTOutputStream::GetOutputStreamPresentationPosition e IMiniportWaveRTOutputStream::GetPacketCount.

Marcas de tiempo del contador de rendimiento

Varias de las rutinas del controlador devuelven marcas de tiempo de contador de rendimiento de Windows que reflejan el momento en el que el dispositivo captura o presenta muestras.

En los dispositivos que tienen canalizaciones DSP complejas y procesamiento de señales, el cálculo de una marca de tiempo precisa puede ser difícil y debe realizarse cuidadosamente. Las marcas de tiempo no deben reflejar simplemente el momento en el que se transfirieron muestras hacia o desde el sistema operativo al DSP.

  • Dentro del DSP, realice un seguimiento de las marcas de tiempo de ejemplo con algún reloj de pared DSP interno.
  • Entre el controlador y DSP, calcule una correlación entre el contador de rendimiento de Windows y el reloj de pared de DSP. Los procedimientos para esto pueden variar desde muy simples (pero menos precisos) hasta bastante complejos o noveles (pero más precisos).
  • Tenga en cuenta los retrasos constantes debido a algoritmos de procesamiento de señales o transportes de canalización o hardware, a menos que se tenga en cuenta estos retrasos.

Operación de lectura de ráfaga

En esta sección se describe la interacción del sistema operativo y del controlador para las lecturas de ráfagas. La lectura de ráfagas puede producirse fuera del escenario de activación de voz siempre que el controlador admita el modelo waveRT basado en paquetes, incluida la función IMiniportWaveRTInputStream::GetReadPacket .

Se describen dos escenarios de lectura de ejemplo de ráfaga. En un escenario, si el minipuerto admite un pin que tiene una categoría de patillas KSNODETYPE_AUDIO_KEYWORDDETECTOR , el controlador comenzará a capturar y almacenar internamente en búfer los datos cuando se detecte una palabra clave. En otro escenario, el controlador puede, opcionalmente, almacenar en búfer datos fuera del búfer de WaveRT si el sistema operativo no lee los datos rápidamente llamando a IMiniportWaveRTInputStream::GetReadPacket.

Para expandir los datos capturados antes de realizar la transición a KSSTATE_RUN, el controlador debe conservar información precisa de la marca de tiempo de ejemplo junto con los datos de captura almacenados en búfer. Las marcas de tiempo identifican el instante de muestreo de las muestras capturadas.

  1. Después de que la secuencia pase a KSSTATE_RUN, el controlador establece inmediatamente el evento de notificación del búfer porque ya tiene datos disponibles.

  2. En este evento, el sistema operativo llama a GetReadPacket() para obtener información sobre los datos disponibles.

    a. El controlador devuelve el número de paquete de los datos capturados válidos (0 para el primer paquete después de la transición de KSSTATE_STOP a KSSTATE_RUN), desde el que el sistema operativo puede derivar la posición del paquete dentro del búfer de WaveRT, así como la posición del paquete relativa al inicio de la secuencia.

    b. El controlador también devuelve el valor del contador de rendimiento que corresponde al instante de muestreo de la primera muestra del paquete. Tenga en cuenta que este valor del contador de rendimiento puede ser relativamente antiguo, en función de la cantidad de datos de captura almacenados en búfer dentro del hardware o controlador (fuera del búfer de WaveRT).

    c. Si hay más datos almacenados en búfer no leídos, el controlador puede: i. Transfiere inmediatamente esos datos al espacio disponible del búfer waveRT (es decir, el espacio no utilizado por el paquete devuelto por GetReadPacket), devuelve true para MoreData y establece el evento de notificación del búfer antes de volver de esta rutina. O bien, ii. Programa hardware para expandir el siguiente paquete en el espacio disponible del búfer waveRT, devuelve false para MoreData y, posteriormente, establece el evento de búfer cuando se completa la transferencia.

  3. El sistema operativo lee los datos del búfer waveRT mediante la información devuelta por GetReadPacket().

  4. El sistema operativo espera el siguiente evento de notificación de búfer. La espera puede finalizar inmediatamente si el controlador establece la notificación del búfer en el paso (2c).

  5. Si el controlador no estableció inmediatamente el evento en el paso (2c), el controlador establece el evento después de transferir más datos capturados al búfer de WaveRT y hace que esté disponible para que el sistema operativo lea.

  6. Vaya a (2). Para KSNODETYPE_AUDIO_KEYWORDDETECTOR patillas del detector de palabras clave, los controladores deben asignar suficiente búfer de ráfaga interna para al menos 5000 ms de datos de audio. Si el sistema operativo no puede crear una secuencia en la patilla antes de que se desborde el búfer, el controlador puede finalizar la actividad de almacenamiento en búfer interno y liberar recursos asociados.

Reactivar la voz

Wake On Voice (WoV) permite al usuario activar y consultar un motor de reconocimiento de voz desde una pantalla apagada, reducir el estado de energía, a una pantalla en estado de alimentación completa diciendo una palabra clave determinada, como "Hey Cortana".

Esta característica permite que el dispositivo siempre escuche la voz del usuario mientras el dispositivo está en un estado de bajo consumo, incluido cuando la pantalla está apagada y el dispositivo está inactivo. Para ello, usa un modo de escucha, que es menor cuando se compara con el uso de energía mucho mayor que se ve durante la grabación normal del micrófono. El reconocimiento de voz de baja potencia permite al usuario simplemente decir una frase clave predefinida como "Hey Cortana", seguida de una frase de voz encadenada como "cuándo es mi próxima cita" para invocar la voz de forma manos libres. Esto funcionará independientemente de si el dispositivo está en uso o inactivo con la pantalla desactivada.

La pila de audio es responsable de comunicar los datos de reactivación (id. de altavoz, desencadenador de palabra clave, nivel de confianza), así como notificar a los clientes interesados que se ha detectado la palabra clave.

Validación en sistemas en espera modernos

WoV desde un estado inactivo del sistema se puede validar en sistemas de espera modernos mediante la moderna reactivación en espera de la prueba básica de voz en la fuente de alimentación de CA y la reactivación en espera moderna en la prueba básica de voz en la fuente de alimentación DC en el HLK. Estas pruebas comprueban que el sistema tiene un spotter de palabra clave de hardware (HW-KWS), puede entrar en el estado de la plataforma inactiva en tiempo de ejecución más profundo (DRIPS) y es capaz de reactivarse desde modern standby en el comando de voz con la latencia de reanudación del sistema de menos o igual que un segundo.