Activación por voz

Nota:

Este tema trata principalmente las soluciones para consumidores que vienen incluidas actualmente en Windows 10 (versión 1909 y anteriores). Para obtener más información, consulte Fin de servicio de Cortana en Windows y Teams.

Cortana, la tecnología de asistente personal se presentó por primera vez en la Microsoft BUILD Developer Conference en 2013. Esta plataforma de voz de Windows se usa para mejorar 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 a partir de varios estados de energía del dispositivo diciendo una frase específica: "Hey Cortana". Para crear hardware que admita la tecnología de activación de voz, consulte la información de este tema.

Nota:

La implementación de la activación por voz es un proyecto de importancia y es un trabajo realizado por los proveedores de SoC. Los OEM pueden ponerse en contacto con el proveedor de SoC para obtener información sobre la implementación de la activación de voz de SoC.

Experiencia de usuario final de Cortana

Para conocer la solución de interacción de voz disponible en Windows, consulte estos temas.

Tema	Descripción
¿Qué es Cortana?	Da información general e instrucciones de uso sobre Cortana

Introducción a la activación de voz "Hey Cortana" ("Hola, Cortana") y "Learn my voice" ("Aprender mi voz")

Activación por voz de "Hey Cortana"

La función de activación por voz (VA) "Hey Cortana" permite a los usuarios interactuar rápidamente con la solución Cortana fuera del contexto activo (es decir, lo que esté actualmente en pantalla) mediante la voz. A menudo, los usuarios quieren acceder al instante a una solución o función sin tener que interactuar físicamente con un dispositivo. Para los usuarios de teléfonos esto puede suceder porque están conduciendo y deben estar atentos a la carretera y tener las manos en el volante. Para un usuario de Xbox, esto puede suceder porque no desea buscar y conectar un controlador. En el caso de los usuarios de PC, esto puede suceder porque quieran acceder rápidamente a una solución o función sin tener que realizar varias acciones con el ratón, tocar la pantalla o usar el teclado (por ejemplo, si tienen el ordenador en la cocina).

La activación por voz escucha siempre lo que se dice mediante la voz a través de frases clave predefinidas o "frases de activación". Las frases clave se pueden enunciar tal cual ("Hey Cortana") como un comando preconfigurado o seguidas de una acción de voz, por ejemplo, "Hey Cortana. where is my next meeting?" ("Hola, Cortana. ¿Dónde tengo mi próxima reunión?"), es decir, un comando encadenado.

El término Detección de palabras clave hace referencia a la detección de la palabra clave mediante hardware o software.

La activación solo de palabra clave se produce cuando solo se dice la palabra clave Cortana. Cortana se ejecuta y reproduce una señal auditiva (EarCon) para indicar que se ha activado el modo de escucha.

Un comando encadenado hace referencia a la capacidad de emitir un comando inmediatamente después de la palabra clave (como "Hey Cortana, call John") ("Hola, Cortana. Llama a John") y hacer que Cortana se ejecute (si aún no lo ha hecho) y responda al comando (llamando por teléfono a John).

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

Microsoft facilita un detector de palabras clave predeterminado del sistema operativo (detector de palabras clave basado en software) que se usa para garantizar la calidad de las detecciones de palabras clave de hardware y activar la experiencia "Hey Cortana" en los casos en que la detección de palabras clave basada en hardware no está instalada o no está disponible.

La función "Learn my voice"

La función "Learn my voice" permite al usuario entrenar a Cortana para reconocer su voz en concreto. Para ello, el usuario selecciona Aprender cómo digo "Hey Cortana" en la pantalla de configuración de Cortana. Hecho esto, el usuario repite seis frases cuidadosamente elegidas que aporten una variedad suficiente de patrones fonéticos para identificar los atributos únicos de la voz del usuario.

Cuando la activación por voz se vincula con "Learn my voice", los dos algoritmos funcionarán juntos para reducir las activaciones falsas. Esto es especialmente útil en salas de reuniones, donde una persona dice "Hey Cortana" en una sala llena de dispositivos. Esta función solo está disponible para Windows 10 versión 1903 y anteriores.

La activación por voz se basa en un detector de palabras clave (KWS) que reacciona si se detecta la frase clave. Si el KWS dese reactivar el dispositivo en un estado de bajo consumo, 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 presenta una lista de términos relacionados con la activación por voz.

Término	Ejemplo/definición
Comando preconfigurado	Ejemplo: Hey Cortana <hay una pausa y espera a la señal auditiva> What’s the weather? ("Hola, Cortana. ¿Qué tiempo hace?") Esto a veces se conoce como "Comando de dos partes" o "Solo palabra clave"
Comando encadenado	Ejemplo: Hey, Cortana what’s the weather? ("Hola, Cortana. ¿Qué tiempo hace?") Esto se conoce a veces como un "comando único"
Activación por voz	Caso al usar la detección de palabras clave de una frase de clave de activación predefinida. Por ejemplo, "Hey Cortana" es el enunciado de activación por voz de Microsoft.
WoV	Wake-on-Voice: Tecnología que habilita la activación por voz cuando la pantalla está apagada, el dispositivo está en modo de bajo consumo y se activa en una pantalla en modo de alto consumo de energía.
WoV en modo de espera moderno	Wake-on-Voice en modo de espera moderno (S0ix) de pantalla apagada a pantalla en modo de alto consumo (S0).
Modo de espera moderno	Infraestructura de inactividad de bajo consumo de Windows: sucesor de Modo de espera conectado (Connected Standby o CS) en Windows 10. El primer modo de espera moderno es cuando la pantalla está apagada. El modo de reposo superior es cuando se encuentra en DRIPS/Resistencia. Para obtener más información, consulte Modo de espera moderno.
KWS	Detector de palabras clave: el algoritmo que habilita la detección de "Hey Cortana"
SW KWS	Detector de palabras clave basado en software: es una implementación de KWS que se ejecuta en el host (CPU). En "Hey Cortana", SW KWS viene incluido dentro de Windows.
HW KWS	Detector de palabras clave basado en hardware: es una implementación de KWS que se ejecuta transferida del hardware.
Búfer en ráfaga	Un búfer circular usado para almacenar datos PCM que puede "ampliarse" en caso de una detección de KWS, de modo que se incluya todo el audio que activó la detección de KWS.
Adaptador OEM del detector de palabras clave	Corrección de compatibilidad de controlador que permite que el hardware compatible con WoV se comunique con Windows y la pila de Cortana.
Modelo	El archivo de datos del modelo acústico usado por el algoritmo de KWS. El archivo de datos es estático. Los modelos vienen localizados, uno por configuración regional.

Integración de un detector de palabras clave basado en hardware

Para implementar un detector de palabras clave basado en hardware (HW KWS), los proveedores de SoC deben realizar las siguientes tareas.

• Cree un detector de palabras clave personalizado basado en el ejemplo SYSVAD descrito más adelante en este tema. Implementará estos métodos en un archivo DLL COM, explicados en Interfaz del adaptador OEM del detector de palabras clave.
• Implemente las mejoras de WAVE RT descritas en Mejoras de WAVERT.
• Cree entradas del archivo INF para describir los APO personalizados que se usan para la detección de palabras clave.
  • PKEY_FX_KeywordDetector_StreamEffectClsid
  • PKEY_FX_KeywordDetector_ModeEffectClsid
  • PKEY_FX_KeywordDetector_EndpointEffectClsid
  • PKEY_SFX_KeywordDetector_ProcessingModes_Supported_For_Streaming
  • PKEY_MFX_KeywordDetector_ProcessingModes_Supported_For_Streaming
  • PKEY_EFX_KeywordDetector_ProcessingModes_Supported_For_Streaming
• Consulte las recomendaciones sobre hardware y la guía de pruebas en Recomendación de dispositivos de audio. En este tema se dan instrucciones y recomendaciones para el diseño y desarrollo de dispositivos de entrada de audio diseñados para usarlos con la Microsoft Speech Platform.
• Admite comandos preconfigurados y encadenados.
• Admite "Hey Cortana" para cada una de las configuraciones regionales de Cortana admitidas.
• Los APO (objetos de procesamiento de audio) deben generar los siguientes efectos:
  • AEC
  • AGC
  • NS
• El APO de MFX debe comunicar los efectos del modo de procesamiento de voz.
• El APO puede realizar la conversión de formato como MFX.
• El APO debe generar el siguiente formato:
  • 16 kHz, mono, FLOAT.
• También puede diseñar los APO personalizados para mejorar el proceso de captura de audio. Para obtener más información, consulte Objetos de procesamiento de audio de Windows.

Requisitos de WoV para el detector de palabras clave basado en hardware (HW KWS)

• HW KWS WoV es compatible durante el modo de trabajo S0 y el modo de suspensión S0 también conocido como Modo de espera moderna.
• HW KWS WoV no funciona con S3.

Requisitos de AEC para HW KWS

• Para versión 1709 de Windows

  • Para que HW KWS WoV pueda funcionar con el modo de reposo S0 (Modo de suspensión moderno), no es necesario AEC.
  • HW KWS WoV en el modo de trabajo S0 no es compatible en la versión 1709 de Windows.

• Para versión 1803 de Windows

  • HW KWS WoV funciona en el modo de trabajo S0.
  • Para habilitar HW KWS WoV en el modo de trabajo S0, el APO debe admitir AEC.

Información general del código de ejemplo

Hay un 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. Para empezar, se recomienda usar este código. 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, consulte Controladores de audio de ejemplo.

Información del sistema de reconocimiento de palabras clave

Funcionalidad de pila de audio de activación por voz

Las interfaces externas de pila de audio para habilitar la activación por voz sirven como proceso 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 del detector de palabras clave (DDI). La interfaz del controlador de dispositivo del detector de palabras clave es responsable de configurar y aprovisionar el detector de palabras clave basado en hardware (KWS). También lo usa el controlador para notificar al sistema de un evento de detección.
• DLL de adaptador 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 y así ayudar con la detección de palabras clave.
• Mejoras de streaming de WaveRT. Las mejoras permiten al controlador de audio ampliar 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 gráficos de puntos de conexión de audio se realiza con normalidad. El gráfico está preparado para realizar las operaciones más rápido que la captura en tiempo real. Las marcas de tiempo en los búferes capturados siguen siendo "true". En concreto, las marcas de tiempo reflejarán correctamente los datos capturados en el pasado y almacenados en búfer y se "expandirán".

Teoría sobre el streaming de audio de derivación por Bluetooth

Como de costumbre, el controlador expone un filtro de KS en el dispositivo de captura. Este filtro admite varias propiedades de KS y un evento de KS para configurar, habilitar y marcar un evento de detección. El filtro también incluye una fábrica de pines adicional identificada como pin de detección de palabras clave (KWS). Este pin se usa para transmitir audio a través del detector de palabras clave.

Las propiedades son las siguientes:

• Tipos de palabras clave admitidas: KSPROPERTY_SOUNDDETECTOR_PATTERNS. El sistema operativo crea esta propiedad para configurar las palabras clave que se van a detectar.
• Lista de GUID de patrones de palabras clave: KSPROPERTY_SOUNDDETECTOR_SUPPORTEDPATTERNS. Esta propiedad se usa para obtener una lista de GUID que identifican los tipos de patrones admitidos.
• Aprovisionado: KSPROPERTY_SOUNDDETECTOR_ARMED. Esta propiedad de lectura y escritura es simplemente un estado booleano que indica si el detector está aprovisionado. El sistema operativo crea esto para interactuar con el detector de palabras clave. El sistema operativo puede borrar esto para desconectarse. El controlador borra esto automáticamente cuando se crean patrones de palabra clave y también después de detectar una palabra clave. (El sistema operativo debe volver a aprovisionarse).
• Resultados de coincidencias: KSPROPERTY_SOUNDDETECTOR_MATCHRESULT. Esta propiedad de lectura alberga los datos de los resultados después de que se haya producido la detección.

El evento que se activa 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 palabra clave admitidos para comprobar que tiene palabras clave en ese formato.
2. El sistema operativo registra el evento de cambio de estado del detector.
3. El sistema operativo crea los patrones de palabras clave.
4. El sistema operativo aprovisiona el detector.

Al recibir el evento de KS

1. El controlador desaprovisiona el detector.
2. El sistema operativo lee el estado del detector de palabras clave, analiza los datos devueltos y determina qué patrón se ha detectado.
3. El sistema operativo vuele a aprovisionar el detector.

Controlador interno y operación de hardware

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

Cuando el hardware detecta una palabra clave, se genera una interrupción. Mientras se espera a que el controlador entre en interrupción, el hardware sigue capturando audio en el búfer, asegurándose de 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 palabras clave

Después de detectar una palabra clave, todas las soluciones de activación por voz deben almacenar en búfer todas las palabras clave enunciadas, incluidos los 250 ms antes del inicio de la palabra clave. El controlador de audio debe indicar las marcas de tiempo que identifiquen el inicio y el final de la frase clave en la transmisión.

Para incorporar las marcas de tiempo iniciales y finales de la palabra clave, el software de DSP podrá necesitar eventos de marca de tiempo internamente basados en un reloj de DSP. Una vez detectada una palabra clave, el software de DSP interactúa con el controlador para preparar un evento de KS. El controlador y el software de 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 del hardware. Una posible solución es que el controlador lea el contador de rendimiento actual, consulte la marca de tiempo de DSP actual, lea de nuevo el contador de rendimiento actual y luego calcule una correlación entre el contador de rendimiento y el tiempo de DSP. Dada la correlación, el controlador puede asignar las marcas de tiempo de DSP a las marcas de tiempo del contador de rendimiento de Windows.

Interfaz del adaptador OEM del detector de palabras clave

El OEM facilita una implementación de objetos 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 del tipo de patrón de detector devuelto por KSPROPERTY_SOUNDDETECTOR_SUPPORTEDPATTERNS. El sistema operativo llama a CoCreateInstance pasando el GUID del tipo de patrón para crear instancias del objeto COM adecuado que sea 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 optar por cualquiera de los modelos de subprocesos COM.

IKeywordDetectorOemAdapter

El diseño de la interfaz intenta mantener la implementación de objetos sin estado. En otras palabras, la implementación no debe exigir que se almacene ningún estado entre las llamadas a los métodos. De hecho, es probable que las clases C++ internas no necesiten ninguna variable miembro, aparte de las necesarias para implementar un objeto COM en general.

Métodos

Implemente los métodos siguientes.

• IKeywordDetectorOemAdapter::BuildArmingPatternData
• IKeywordDetectorOemAdapter::ComputeAndAddUserModelData
• IKeywordDetectorOemAdapter::GetCapabilities
• IKeywordDetectorOemAdapter::ParseDetectionResultData
• IKeywordDetectorOemAdapter::VerifyUserKeyword

KEYWORDID

La enumeración KEYWORDID identifica el texto o la 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 sistema 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 de usuario estático: el archivo DLL de OEM normalmente incluiría algunos datos del modelo independiente de usuario estático integrados en el DLL o en un archivo de datos independiente incluido con el DLL. Los identificadores de palabras clave admitidos devueltos por la rutina GetCapabilities dependerán de estos datos. Por ejemplo, si la lista de identificadores de palabras clave admitidos devueltos por GetCapabilities incluye KwHeyCortana, los datos del modelo independiente de usuario estático incluirían datos para "Hey Cortana" (o su traducción) en todos los idiomas admitidos.

Modelo dependiente de usuario dinámico: IStream facilita 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 de hasta 1 MB de datos.

El OEM define el contenido y la estructura de los datos dentro de este almacenamiento. La finalidad prevista es para el almacenamiento persistente de los datos del modelo dependiente de usuario calculados o recuperados por el DLL del 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 del 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 hacer una comprobación del 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án, lo que permite que el resto del método acceda solo a IStream en todos los datos del modelo.

Procesamiento de audio de operación y entrenamiento

Como se ha descrito anteriormente, el flujo de la interfaz de usuario de entrenamiento da como resultado frases bien elaboradas fonéticamente y disponibles en la transmisión de audio. Cada una de las frases pasa a IKeywordDetectorOemAdapter::VerifyUserKeyword para comprobar que incluye la palabra clave esperada y tiene una calidad aceptable. Una vez recopiladas y verificadas todas las frases 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 por voz y el uso normal del reconocimiento de voz.

|

	Entrenamiento de voz	Reconocimiento de voz
Modo	Sin procesar	Sin procesar o voz
Pin	Normal	KWS
Formato de audio	Float de 32 bits (Tipo = Audio, Subtipo = IEEE_FLOAT, Frecuencia de muestreo = 16 kHz, bits = 32)	Administrado por pila de audio del sistema operativo
Micrófono	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 da información general sobre el sistema de reconocimiento de palabras clave.

Diagramas de secuencia de reconocimiento de palabras clave

En estos diagramas, el módulo de voz en ejecución se muestra como la "plataforma de voz". Como se ha indicado anteriormente, la plataforma de voz de Windows se usa para mejorar todas las soluciones y funciones de voz en Windows 10, como Cortana y Dictado.

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

Después, cuando el usuario selecciona "Learn my voice", se invoca el flujo de entrenamiento.

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

Mejoras de WAVERT

Las interfaces minipuerto se definen para que las implementen los controladores minipuerto WaveRT. Estas interfaces ofrecen métodos para simplificar el controlador de audio, mejorar el rendimiento y la fiabilidad del procesamiento de audio del sistema operativo, así como admitir nuevos mecanismos. Se define una nueva propiedad de interfaz de dispositivo PnP que permite al controlador generar expresiones estáticas de sus restricciones de tamaño de búfer en el sistema operativo.

Tamaños de búfer

Un controlador funciona con varias restricciones al mover datos de audio entre el sistema operativo, el controlador y el hardware. Estas restricciones pueden derivarse del 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 duraciones 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 de dispositivo DEVPKEY_KsAudio_PacketSize_Constraints en la interfaz de dispositivo PnP KSCATEGORY_AUDIO del filtro de KS que tiene pines de streaming. Esta propiedad debe ser siempre válida y estable mientras la interfaz del filtro de KS está habilitada. El sistema operativo puede leer este valor en cualquier momento sin tener que abrir un identificador en el controlador y llamar al controlador.

DEVPKEY_KsAudio_PacketSize_Constraints

El valor de la propiedad DEVPKEY_KsAudio_PacketSize_Constraints incluye una estructura KSAUDIO_PACKETSIZE_CONSTRAINTS que describe las restricciones de hardware físico (es decir, debido al modo 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 los modos de procesamiento de señal. El controlador crea esta propiedad antes de llamar a PcRegisterSubdevice o habilitar la interfaz de filtro de KS para sus pines de streaming.

IMiniportWaveRTInputStream

Un controlador implementa esta interfaz para coordinar mejor el flujo de datos de audio del controlador al sistema operativo. Si esta interfaz está disponible en una transmisión 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, consulte IMiniportWaveRTInputStream::GetReadPacket

IMiniportWaveRTOutputStream

Un minipuerto WaveRT implementa de forma opcional esta interfaz para que se le indique el progreso de escritura desde el sistema operativo y para devolver una posición precisa de la transmisión. Para obtener más información, consulte IMiniportWaveRTOutputStream::SetWritePacket, IMiniportWaveRTOutputStream::GetOutputStreamPresentationPosition y IMiniportWaveRTOutputStream::GetPacketCount.

Marcas de tiempo del contador de rendimiento

Varias de las rutinas del controlador devuelven marcas de tiempo del contador de rendimiento de Windows que reflejan la hora en la que el dispositivo captura o presenta los muestreos.

En los dispositivos que tienen procesos de DSP y procesamientos de señales complejos, calcular una marca de tiempo precisa puede ser difícil y esto se debe realizar con cuidado. Las marcas de tiempo no deben reflejar solo el momento en el que los muestreos se han transferido al sistema operativo o desde este al DSP.

• Dentro del DSP, compruebe las marcas de tiempo de los muestreos mediante un reloj de DSP interno.
• Entre el controlador y el DSP, calcule la correlación entre el contador de rendimiento de Windows y el reloj de DSP. Los procedimientos destinado a esto pueden ser muy sencillos (pero menos precisos) a bastante complejos o nuevos (pero más precisos).
• Fíjese en los retrasos constantes por los algoritmos de procesamiento de señales o los transportes de procesos o hardware, a menos que estos retrasos se contabilicen de otra manera.

Operación de lectura en ráfaga

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

Aquí se presentan dos situaciones de ejemplo de lecturas en ráfagas. En un caso, si el minipuerto admite un pin que tiene la categoría de pin KSNODETYPE_AUDIO_KEYWORDDETECTOR, el controlador empezará a capturar y almacenar en búfer los datos internamente cuando se detecte una palabra clave. En otro caso, el controlador puede almacenar internamente 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 tener 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 transmisión pase a KSSTATE_RUN, el controlador cree 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 paquetes 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 pueda derivar la posición del paquete dentro del búfer de WaveRT, así como la posición del paquete relativa al inicio de la transmisión.

   b. El controlador también devuelve el valor del contador de rendimiento que corresponda 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 de hardware o controlador (fuera del búfer de WaveRT).

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

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

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

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

6. Vaya al paso (2). En los pines del detector de palabras clave KSNODETYPE_AUDIO_KEYWORDDETECTOR, los controladores deben asignar suficiente almacenamiento en búfer en ráfagas interno para al menos 5000 ms de datos de audio. Si el sistema operativo no puede crear una transmisión en el pin antes de que se desborde el búfer, el controlador puede finalizar la actividad de almacenamiento en búfer interno y liberar recursos asociados.

Wake on Voice

Wake On Voice (WoV) permite al usuario activar y consultar un motor de reconocimiento de voz con la pantalla apagada, con el modo de bajo consumo de energía, con una pantalla en modo de alto consumo diciendo una palabra clave determinada, como "Hey Cortana".

Esta función permite que el dispositivo siempre escuche la voz del usuario mientras el dispositivo está en un estado de bajo consumo, además de cuando la pantalla está apagada y el dispositivo está inactivo. Para ello, usa un modo de escucha, que es de bajo consumo si lo comparamos con el uso de energía mucho mayor durante la grabación normal de un micrófono. El reconocimiento de voz de bajo consumo permite al usuario decir una frase clave predefinida como "Hey Cortana", seguida de una frase de voz encadenada como "¿Cuándo tengo la cita?" para invocar la voz de forma práctica. Esto funcionará independientemente de si el dispositivo está en uso o inactivo y con la pantalla apagada.

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 informar a los clientes interesados de que se ha detectado la palabra clave.

Validación en sistemas de modo de espera moderno

A partir de un estado de inactividad del sistema, WoV se puede validar en Modo de espera moderno mediante reactivación en espera moderna en la prueba básica de voz en la fuente de alimentación CA y la Wake on Voice en modo de espera moderna en la prueba básica de voz en la fuente de alimentación de DC en el HLK. Estas pruebas verifican que el sistema tiene un detector de palabras clave basado en hardware (HW-KWS), puede entrar en el estado de la plataforma inactiva en ejecución más profundo (DRIPS) y es capaz de reactivarse desde Modo de espera moderno en el comando de voz con la latencia de reanudación del sistema de menos o igual a un segundo.