Asistente para voz múltiple

La plataforma Multiple Voice Assistant ofrece la opción de incluir más asistentes de voz en Windows. Esto permite que otros asistente estén disponibles en dispositivos Windows, como equipos y dispositivos portátiles como HoloLens. Se pueden activar varios asistentes de voz en el mismo dispositivo mediante un conjunto de patrones de palabras clave aceptadas.

Nota:

Multiple Voice Assistant es compatible a partir de la versión 1903 de Windows 10.

Para obtener información sobre cómo implementar Windows Cortana, consulte Activación por voz.

Activación por voz

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 modos de consumo de energía del dispositivo diciendo una frase específica.

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.

La activación por voz permite a los usuarios interactuar rápidamente con la solución de asistente de voz 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 o con acciones táctiles con un dispositivo. 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 se basa en un detector de palabras clave (KWS) que reacciona si se detecta la frase clave. Las frases clave pueden incluir palabras clave como "Hey Contoso". La detección de palabras clave describe la detección de la palabra clave mediante hardware o software.

Las frases clave se pueden pronunciar por sí mismas ("Hey Contoso") como un comando preconfigurado o seguidas de una acción de voz que forma un comando encadenado, por ejemplo, "Hey Contoso, where is my next meeting?" ("Hola, Contoso. ¿Dónde tengo mi próxima reunión?")

Microsoft incluye un detector de palabras clave predeterminado del sistema operativo (detector de palabras clave basado en software) para usar una solución de asistente de voz en los casos en los que la detección de palabras clave de hardware no esté disponible. Aunque está disponible actualmente en Cortana, es posible que se necesiten realizar otros ajustes de Microsoft para incorporar otras asistente de voz y así realizar la detección de palabras clave en dos fases. Para obtener más información, póngase en contacto con AskMVA@Microsoft.com.

Si el KWS se usa para 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 más adelante en este artículo.

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 Contoso <pausa y espera a la IU del asistente> What's the weather? ("Hola, Contoso. ¿Qué tiempo hace?") Esto a veces se conoce como "Comando de dos partes" o "Solo palabra clave"
Comando encadenado	Ejemplo: Hey Contoso what's the weather? ("Hola, Contoso. ¿Qué tiempo hace?") Esto se conoce a veces como un "comando único"
Activación por voz	Ejemplo: "Hey Contoso" Aquí es donde se detecta la palabra clave en una frase clave de activación predefinida.
Wake-on-Voice (WoV)	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).
En espera moderna	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 Contoso".
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 eventos	Componente de modo de usuario que actúa como intermediario entre la pila del asistente de voz de Windows y el controlador.
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.
MVA	Agente de voz múltiple (Multiple Voice Agent): La DDI de HWKWS que admite varios agentes.
SVA	Agente de voz único (Single Voice Agent): La DDI HWKWS anterior que solo admite un único agente (Cortana).

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 de IEvent Detector.
• 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.
• Cumplir los requisitos de configuración regional de los asistentes de voz
• 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.

AEC

AEC se puede realizar mediante el DSP en el momento en que se captura el audio en ráfaga, o bien se puede realizar más adelante a través de un APO de software. Para realizar un AEC de software con datos en ráfaga de KWS, es necesario tener el audio de bucle invertido correspondiente desde el momento en que se capturaron los datos en ráfaga. Para ello, se ha creado un formato de audio personalizado para la salida en ráfaga que intercala el audio de bucle invertido en los datos de audio en ráfaga.

A partir de la versión 20H1 de Windows, el APO de Microsoft AEC identifica de este formato de intercalado y puede usarlo para realizar el AEC. Para obtener más información, consulte KSPROPERTY_INTERLEAVEDAUDIO_FORMATINFORMATION.

Validation

Valide la compatibilidad de HW con las propiedades KSPROPSETID_SoundDetector2 mediante las pruebas del Administrador de activación de voz 2.

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.

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 (DDI) del detector de eventos. La interfaz del controlador de dispositivo del detector de eventos 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 del adaptador OEM de IEvent Detector. 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 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.

La propiedad es: KSPROPSETID_SoundDetector2

Se llama a todas las propiedades KSPROPSETID_SoundDetector2 con la estructura de datos KSSOUNDDETECTORPROPERTY. Esta estructura de datos incluye KSPROPERTY y el ID de evento de la palabra clave que se va a aprovisionar, restablecer, detectar, etc.

• 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).
• Resultado de coincidencia: KSPROPERTY_SOUNDDETECTOR_RESET se usa para restablecer el detector de sonido al momento que se inicia.

En el momento en que se detectan palabras clave, se envía una notificación PNP que incluye KSNOTIFICATIONID_SoundDetector. NOTA: Esto no es un KSEvent, sino un evento PNP que se envía, con una carga, a través de IoReportTargetDeviceChangeAsynchronous.

KSNOTIFICATIONID_SoundDetector se define en ksmedia.h, tal como aparece aquí.

// The payload of this notification is a SOUNDDETECTOR_PATTERNHEADER
#define STATIC_KSNOTIFICATIONID_SoundDetector\
    0x6389d844, 0xbb32, 0x4c4c, 0xa8, 0x2, 0xf4, 0xb4, 0xb7, 0x7a, 0xfe, 0xad
DEFINE_GUIDSTRUCT("6389D844-BB32-4C4C-A802-F4B4B77AFEAD", KSNOTIFICATIONID_SoundDetector);
#define KSNOTIFICATIONID_SoundDetector DEFINE_GUIDNAMED(KSNOTIFICATIONID_SoundDetector)

Secuencia de operación

Inicio del sistema

1. El sistema operativo envía un KSPROPERTY_SOUNDDETECTOR_RESET para borrar cualquier estado de detector anterior, restableciendo todos los detectores para desaprovisionarlos y borrar los patrones anteriores creados.
2. El sistema operativo consulta KSPROPERTY_SOUNDDETECTOR_PATTERNS para recuperar el clsid del adaptador OEM del detector de eventos.
3. El sistema operativo usa el adaptador OEM del detector de eventos para recuperar la lista de palabras clave e idiomas admitidos.
4. El sistema operativo se registra para activar las notificaciones PNP personalizadas enviadas por el controlador
5. El sistema operativo establece los patrones de palabras clave necesarios.
6. El sistema operativo aprovisiona el detector o detectores.

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 1,6 s 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 de IEvent Detector

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 IEventDetectorOemAdapter del objeto.

Requisitos del modelo de subprocesos COM

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

IEventDetectorOemAdapter

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.

• IEventDetectorOemAdapter::BuildArmingPatternData
• IEventDetectorOemAdapter::ComputeAndAddUserModelData
• IEventDetectorOemAdapter::GetCapabilities
• IEventDetectorOemAdapter::GetCapabilitiesForLanguage
• IEventDetectorOemAdapter::ParseDetectionResultData
• IEventDetectorOemAdapter::ReportOSDetectionResult
• IEventDetectorOemAdapter::VerifyUserEventData

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 ha definido una 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_Constraints2 en la interfaz de dispositivo PnP KSCATEGORY_AUDIO del filtro de KS que tiene los 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_Constraints2

El valor de la propiedad DEVPKEY_KsAudio_PacketSize_Constraints2 incluye una estructura KSAUDIO_PACKETSIZE_CONSTRAINTS2 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 del modo de bajo consumo de energía al modo de alto consumo con la pantalla encendida, enunciando una palabra clave determinada, como "Hey Contoso".

Esta característica permite que el dispositivo siempre escuche la voz del usuario mientras el dispositivo está inactivo y la pantalla está apagada. Esto se debe al modo de escucha que usa mucho menos energía en comparación con la grabación normal del micrófono. WoV permite decir frases de voz encadenadas como "Hey Contoso, when's my next appointment" ("Hola, Contoso. ¿Cuándo tengo la cita?") para invocar una respuesta de un asistente de voz en modo de manos libres.

La pila de audio es responsable de comunicar los datos de reactivación (ID de altavoz, desencadenador de palabra clave, información de contexto según 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.

ACX y MVA

Audio Class eXtension (ACX) define una extensión de clase de Windows Driver Framework (WDF) para el dominio de audio. Para obtener más información sobre ACX, consulte Información general sobre las extensiones de clase de audio (ACX) y Resumen de objetos de ACX. En esta sección se describe cómo implementar MVA mediante ACX.

ACX usa la misma infraestructura de KS para el detector de palabras clave, incorporando una capa de abstracción para simplificar la implementación del controlador. Con ACX, se usa el misma DLL del OEM como se ha descrito anteriormente y se queda sin cambios. AcX y Portcls necesitan la interfaz IEventDetectorOEMAdapter y no hay ninguna diferencia en la implementación entre los dos para el adaptador OEM.

La función AcxKeywordSpotterCreate se usa para crear un objeto opaco de detección de palabra clave de ACX (ACXKEYWORDSPOTTER) que se asociará a un objeto de dispositivo de circuito principal.

El objeto ACXKEYWORDSPOTTER se usa para reemplazar todas las llamadas KSPROPERTY_SOUNDDETECTOR, lo que simplifica la implementación de KWS. Se utiliza en el proceso de agregar un elemento de KWS y un pin de KWS al circuito de ACX. Las devoluciones de llamada asociadas se encargan de obtener los patrones, aprovisionándolos, desaprovisionándolo y restableciéndolos. Usa una estructura ACX_KEYWORDSPOTTER_CONFIG inicializada que describe la configuración del detector de palabras clave.

La estructura ACX_KEYWORDSPOTTER_CONFIG toma una estructura ACX_KEYWORDSPOTTER_CALLBACKS que define las siguientes devoluciones de llamada.

EvtAcxKeywordSpotterRetrieveArm: la devolución de llamada de ACX_KEYWORDSPOTTER_RETRIEVE_ARM.

EvtAcxKeywordSpotterAssignArm: la devolución de llamada de ACX_KEYWORDSPOTTER_ASSIGN_ARM.

EvtAcxKeywordSpotterAssignPatterns: la devolución de llamada de ACX_KEYWORDSPOTTER_ASSIGN_PATTERNS.

EvtAcxKeywordSpotterAssignReset: la devolución de llamada de ACX_KEYWORDSPOTTER_ASSIGN_RESET.

Evento PNP de ACX

El evento PNP de ACX reemplaza KSNOTIFICATIONID_SoundDetector, lo que simplifica el evento de notificación de detección. La función ACX_PNPEVENT_CONFIG_INIT inicializa una estructura ACX_PNPEVENT_CONFIG. No se usan entradas con esta función.

Ejemplo de código de ACX KWS

El código de ejemplo de ACX KWS refleja la inicialización de las devoluciones de llamada, los elementos de palabra clave y la creación del detector de palabras clave.

{
    NTSTATUS                        status;
    WDF_OBJECT_ATTRIBUTES           attributes;
    ACX_KEYWORDSPOTTER_CALLBACKS    keywordSpotterCallbacks;
    ACX_KEYWORDSPOTTER_CONFIG       keywordSpotterCfg;
    PCODEC_KEYWORDSPOTTER_CONTEXT   keywordSpotterCtx;
    ACX_PNPEVENT_CONFIG             keywordEventCfg;
    ACXPNPEVENT                     keywordEvent;

    PAGED_CODE();

    ACX_KEYWORDSPOTTER_CALLBACKS_INIT(&keywordSpotterCallbacks);
    keywordSpotterCallbacks.EvtAcxKeywordSpotterRetrieveArm = CodecC_EvtAcxKeywordSpotterRetrieveArm;
    keywordSpotterCallbacks.EvtAcxKeywordSpotterAssignArm = CodecC_EvtAcxKeywordSpotterAssignArm;
    keywordSpotterCallbacks.EvtAcxKeywordSpotterAssignPatterns = CodecC_EvtAcxKeywordSpotterAssignPatterns;
    keywordSpotterCallbacks.EvtAcxKeywordSpotterAssignReset = CodecC_EvtAcxKeywordSpotterAssignReset;
    
    ACX_KEYWORDSPOTTER_CONFIG_INIT(&keywordSpotterCfg);
    keywordSpotterCfg.Pattern = &CONTOSO_KEYWORDCONFIGURATION_IDENTIFIER2;
    keywordSpotterCfg.Callbacks = &keywordSpotterCallbacks;
    
    WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE(&attributes, CODEC_KEYWORDSPOTTER_CONTEXT);
    attributes.ParentObject = Circuit;

Luego, la función AcxKeywordSpotterCreate se usa para crear el objeto del detector de palabras clave de ACX y asociarlo a un circuito existente.

    status = AcxKeywordSpotterCreate(Circuit, &attributes, &keywordSpotterCfg, Element);
    if (!NT_SUCCESS(status))
    {
        ASSERT(FALSE);
        goto exit;
    }

A continuación, se determina el contexto del detector de palabras clave y se usa para crear KeywordDetector en la memoria NonPagedPoolNx.

    
    keywordSpotterCtx = GetCodecKeywordSpotterContext(*Element);
    ASSERT(keywordSpotterCtx);
    
    keywordSpotterCtx->KeywordDetector = (PVOID) new(NonPagedPoolNx, DRIVER_TAG) CKeywordDetector();
    if (keywordSpotterCtx->KeywordDetector == NULL)
    {
        status = STATUS_INSUFFICIENT_RESOURCES;
        ASSERT(FALSE);
        goto exit;
    }

En este código de ejemplo, la clase CKeywordDetector que se agrega al contexto solo se facilita como una implementación de ejemplo que simula la detección de palabras clave dentro del controlador de ejemplo. La clase CKeywordDetector no forma parte de la estructura de ACX ni es pieza indispensable de la implementación de MVA en ACX, pero puede suponer un buen punto de partida para el desarrollo de un detector de palabras clave real.

Por último, el evento PnP de ACX se configura y crea.

   
    ACX_PNPEVENT_CONFIG_INIT(&keywordEventCfg);
    
    WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE(&attributes, CODEC_PNPEVENT_CONTEXT);
    attributes.ParentObject = *Element;
    status = AcxPnpEventCreate(Device, *Element, &attributes, &keywordEventCfg, &keywordEvent);
    if (!NT_SUCCESS(status))
    {
        ASSERT(FALSE);
        goto exit;
    }

    keywordSpotterCtx->Event = keywordEvent;

    //
    // Done. 
    //
    status = STATUS_SUCCESS;

}

Circuitos con operaciones complejas de pines, incluido KWS

En el caso de los circuitos con operaciones complejas de pines, como circuitos con motor host o KWS, el controlador debe deshabilitar ACX para controlar los puentes de transmisión y, en su lugar, crear un puente de transmisión sin inmode. Este procedimiento impide que ACX asocie automáticamente transmisiones a puentes de transmisión.

Consulte también

Activación por voz