Asistente para voz múltiple

La plataforma Multiple Voice Assistant proporciona compatibilidad con asistentes de voz adicionales en Windows. Esto permite que otros asistentes estén disponibles en dispositivos Windows, como equipos y dispositivos portátiles como HoloLens. Varios asistentes de voz pueden estar activos en el mismo dispositivo mediante un conjunto de patrones de palabras clave compatibles.

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

Activación de voz

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.

La implementación de la activación por voz es un proyecto significativo 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 la activación de voz de SoC.

La activación por voz permite a los usuarios interactuar rápidamente con la experiencia del asistente de voz 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 o tocarlo. Para un usuario de Xbox, puede que no quiera buscar y conectar un controlador. En el caso de los usuarios de PC, es posible que quieran un acceso rápido a una experiencia sin tener que realizar varias acciones del mouse, la entrada táctil o el teclado, como en el caso de un ordenador en la cocina.

La activación por voz se basa en un spotter de palabras clave (KWS) que reacciona si se detecta la frase clave. Las frases clave pueden incluir palabras clave como "Hola Contoso". La detección de palabras clave describe la detección de la palabra clave por 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 compone un comando encadenado ("Hey Contoso, donde es mi próxima reunión?")

Microsoft proporciona un spotter de palabras clave predeterminado del sistema operativo (spotter de palabras clave de software) para proporcionar experiencia de asistente de voz en los casos en los que la detección de palabras clave de hardware no está disponible. Aunque esto está disponible actualmente para Cortana, es posible que se necesite una configuración adicional de Microsoft para incorporar otros asistentes de voz para 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 KWS debe reactivar el dispositivo desde 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 resumen los términos relacionados con la activación por voz.

Integrando un detector de palabras clave de hardware

Para implementar un spotter de palabra clave de hardware (HW KWS) los proveedores de SoC deben completar 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, que se describe en IEvent Detector OEM Adapter Interface (Interfaz del adaptador oem de IEvent Detector).
• Implemente mejoras de WAVE RT descritas en Mejoras de WAVERT.
• Proporcione entradas de archivo INF para describir las API personalizadas que se usan para la detección de palabras clave.
  • PKEY_FX_KeywordDetector_StreamEffectClsid
  • PKEY_FX_KeywordDetector_ModeEffectClsid
  • PKEY_FX_KeywordDetector_EndpointEffectClsid
  • PKEY_SFX_DetectorDePalabrasClave_ModosDeProcesamiento_CompatiblesParaTransmisión
  • PKEY_MFX_KeywordDetector_ProcessingModes_Supported_For_Streaming
  • PKEY_EFX_KeywordDetector_ProcessingModes_Supported_For_Streaming
• Revise las recomendaciones de hardware y las instrucciones de prueba en Recomendación de dispositivos de audio. En este tema se proporcionan instrucciones y recomendaciones para el diseño y desarrollo de dispositivos de entrada de audio diseñados para su uso con la Plataforma de voz de Microsoft.
• Admite comandos por etapas y encadenados.
• Cumplir los requisitos de configuración regional de los asistentes de voz
• Las API (objetos de procesamiento de audio) deben proporcionar los siguientes efectos:
  • AEC
  • AGC
  • NS
• El APO de MFX debe notificar 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.
• Opcionalmente, diseñe las API personalizadas para mejorar el proceso de captura de audio. Para obtener más información, vea Objetos de procesamiento de audio de Windows.

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

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

AEC

AEC se puede llevar a cabo mediante el DSP en el momento en que se captura el audio de ráfaga, o bien se puede efectuar más adelante a través de un APO de software. Para realizar un AEC de software con datos de burst de KWS, es necesario tener el audio de loopback correspondiente desde el momento en que se capturaron los datos de burst. Para ello, se creó un formato de audio personalizado para la salida de ráfaga que intercala el audio de retroalimentación en los datos de audio de ráfaga.

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

Validación

Valide la compatibilidad de HW con las propiedades de KSPROPSETID_SoundDetector2 mediante las pruebas de Voice Activation Manager 2.

Introducción al código de ejemplo

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

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

Compatibilidad con el stack de audio de activación por voz

Las interfaces externas del stack de audio para habilitar la activación por voz sirven como tubería 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 del dispositivo detector de eventos es responsable de configurar y activar el detectador de palabras clave por hardware (KWS). También lo usa el controlador para notificar al sistema 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 para ayudar con la detección de palabras clave.
• Mejoras de WaveRT. Las mejoras permiten al controlador de audio transmitir en ráfaga 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 lleva a cabo normalmente. El gráfico está preparado para manejar capturas de datos más rápido que el tiempo real. Las marcas de tiempo en los búferes capturados permanecen verdaderas. En concreto, las marcas de tiempo reflejarán correctamente los datos que fueron capturados en el pasado y almacenados en búfer, y que ahora están estallando.

Teoría del streaming de audio de evasió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 indicar un evento de detección. El filtro también incluye una fábrica de pines adicional, identificada como un pin de detección de palabras clave (KWS). Este pin se usa para transmitir audio desde el spotter de palabras clave.

La propiedad es: KSPROPSETID_SoundDetector2

Todas las propiedades KSPROPSETID_SoundDetector2 se llaman con una estructura de datos KSSOUNDDETECTORPROPERTY. Esta estructura de datos contiene KSPROPERTY y el identificador de evento de la palabra clave que se va a armar, restablecer, detectar, etc.

• 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 interactuar con el detector de palabras clave. El sistema operativo puede borrar esto para desconectarse. 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_RESET se usa para restablecer el detector de sonido en tiempo de inicio.

En el momento de la detección de palabras clave, se envía una notificación PNP que contiene 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 como se muestra 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 desarmar y borrar los patrones anteriores establecidos.
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 y idiomas admitidos.
4. El sistema operativo realiza el registro para notificaciones PNP personalizadas enviadas por el controlador.
5. El sistema operativo establece los patrones de palabra clave necesarios.
6. El sistema operativo arma los detectores

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 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 es tal que, mientras está armado, no hay ninguna interacción entre el controlador y el hardware y no hay interrupciones en los procesadores de 'aplicaciones' hasta que se detecte una palabra clave. Esto permite que el sistema alcance un estado de potencia inferior si no hay ninguna otra actividad.

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

Marcas de tiempo de palabras clave

Después de detectar una palabra clave, todas las soluciones de activación de voz deben almacenar en búfer la totalidad de la palabra clave hablada, incluidas las 1.6 s 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 de inicio/fin de la palabra clave, el software DSP puede necesitar marcar internamente eventos 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 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 de hardware. Una posible solución es que el controlador lea el contador de rendimiento actual, consulte la marca de tiempo DSP actual, lea de nuevo el contador de rendimiento actual y, a continuación, calcule una correlación entre el contador de rendimiento y el tiempo de DSP. Luego, dada la correlación, el controlador de dispositivo 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 proporciona 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 de tipo de patrón de detector devuelto por el KSPROPERTY_SOUNDDETECTOR_SUPPORTEDPATTERNS. El sistema operativo llama a CoCreateInstance, pasando el GUID del tipo de patrón, para crear una instancia del objeto COM apropiado que sea compatible con el tipo de patrón de palabras clave y llama a los métodos en la interfaz IEventDetectorOemAdapter del objeto.

Requisitos del modelo de subprocesos COM

La implementación del OEM puede elegir cualquiera de los modelos de threading 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 requerir que se almacene ningún estado entre las llamadas al 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.

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

Mejoras de WAVERT

Las interfaces de miniporte se definen para que las implementen 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 propiedad de interfaz de dispositivo PnP 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 con 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.

HW-KWS soluciones 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 de dispositivo DEVPKEY_KsAudio_PacketSize_Constraints2 en la interfaz de dispositivo PnP de KSCATEGORY_AUDIO del filtro KS que tiene los pines de transmisión 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 del controlador e invocar al controlador.

DEVPKEY_KsAudio_PacketSize_Constraints2

El valor de la propiedad DEVPKEY_KsAudio_PacketSize_Constraints2 contiene una estructura KSAUDIO_PACKETSIZE_CONSTRAINTS2 que describe las restricciones de hardware físico (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 los modos de procesamiento de señal. El controlador establece esta propiedad antes de llamar a PcRegisterSubdevice o habilitar su interfaz de filtro 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 un flujo 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

Un minipuerto WaveRT implementa opcionalmente esta interfaz para ser notificado del progreso de escritura por el sistema operativo y para devolver una 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 del contador de rendimiento de Windows que reflejan la hora en la que el dispositivo captura o presenta las muestras.

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

• Dentro del DSP, realice un seguimiento de las marcas de tiempo de las muestras mediante un reloj interno del DSP.
• Entre el controlador y DSP, calcule una correlación entre el contador de rendimiento de Windows y el reloj de pared DSP. Los procedimientos para esto pueden ser muy simples (pero menos precisos) a 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 estos retrasos se contabilizan de otra manera.

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áfaga. La lectura de ráfagas puede producirse fuera del escenario de activación de voz siempre que el controlador admita el modelo WaveRT de streaming basado en paquetes, incluida la función IMiniportWaveRTInputStream::GetReadPacket .

Se discuten dos escenarios de ejemplo de lectura de ráfaga. En un escenario, si el miniport admite un pin que tiene una categoría de pin KSNODETYPE_AUDIO_KEYWORDDETECTOR, el controlador comenzará a capturar y almacenar en búfer los datos internamente cuando se detecte una palabra clave. En otro escenario, 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 vaciar 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 muestra 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 del flujo.

   b. El controlador también devuelve el valor del contador de rendimiento que corresponde al instante de muestreo del primer ejemplo 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 ya sea: 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 establece el evento de notificación del búfer antes de volver de esta rutina. O, ii. Se programa el hardware para enviar en ráfaga el siguiente paquete al espacio disponible del búfer WaveRT, devuelve 'false' para MoreData, y posteriormente, activa el evento del búfer cuando se completa la transferencia.

3. El sistema operativo lee 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 terminar de inmediato 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. Ir a (2).

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

Reactivación por voz

Wake-on-Voice (WoV) permite al usuario activar y consultar un motor de reconocimiento de voz desde un estado de baja potencia a un estado de potencia completa con la pantalla encendida al decir 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á desactivada. Esto se debe al modo de escucha que usa mucho menos potencia en comparación con la grabación normal del micrófono. WoV permite una frase de voz encadenada como "Hey Contoso, ¿cuándo es mi próxima cita?" para invocar una respuesta de un asistente de voz de forma manos libres.

El sistema de audio es responsable de comunicar los datos de activación (identificador de altavoz, activador de palabra clave, información contextual sobre el nivel de confianza) y de notificar a los clientes interesados que se ha detectado la palabra clave.

Validación en sistemas en espera modernos

WoV desde un estado de inactividad del sistema se puede validar en los sistemas de Modern Standby mediante la Prueba Básica de Reactivación por Voz en Espera Moderna con Fuente de Alimentación CA y la Prueba Básica de Reactivación por Voz en Espera Moderna con Fuente de Alimentación CC en el HLK. Estas pruebas comprueban que el sistema tiene un detector de palabras clave por hardware (HW-KWS), puede entrar en el estado de reposo más profundo de la plataforma en tiempo de ejecución (DRIPS) y es capaz de reactivarse desde el modo de espera moderno por comando de voz, con una latencia de reanudación del sistema menor o igual a un segundo.

ACX y MVA

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

ACX utiliza la misma infraestructura de KS para el detector de palabras clave, agregando una capa de abstracción para simplificar la implementación del controlador. Con ACX, se usa la misma DLL de OEM como se ha descrito anteriormente y permanece sin cambios. AcX y Portcls requieren 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 detector de palabras clave ACX (ACXKEYWORDSPOTTER) que se asociará a un objeto principal de dispositivo de circuito.

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 KWS y una patilla KWS al circuito ACX. Las devoluciones de llamada asociadas se encargan de obtener los patrones, activar, desactivar y restablecer. Usa una estructura de ACX_KEYWORDSPOTTER_CONFIG inicializada que describe la configuración del spotter de palabras clave.

La estructura ACX_KEYWORDSPOTTER_CONFIG acepta una estructura ACX_KEYWORDSPOTTER_CALLBACKS que define las siguientes funciones de devolución de llamada.

EvtAcxKeywordSpotterRetrieveArm: devolución de llamada ACX_KEYWORDSPOTTER_RETRIEVE_ARM .

EvtAcxKeywordSpotterAssignArm: la callback ACX_KEYWORDSPOTTER_ASSIGN_ARM.

EvtAcxKeywordSpotterAssignPatterns: devolución de llamada ACX_KEYWORDSPOTTER_ASSIGN_PATTERNS .

EvtAcxKeywordSpotterAssignReset: devolución de llamada ACX_KEYWORDSPOTTER_ASSIGN_RESET .

ACX PNP Evento

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.

Código de ejemplo de ACX KWS

El código de ejemplo de ACX KWS muestra la inicialización de los callbacks, 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;

A continuación, se usa la función AcxKeywordSpotterCreate para crear el objeto de spotter de palabra clave 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 utiliza para crear el 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 proporciona 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 del marco de ACX ni de una parte necesaria de la implementación de MVA en ACX, pero puede proporcionar un buen punto de partida para el desarrollo de un spotter de palabras clave real.

Por último, el evento ACX PnP queda configurado y creado.

   
    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 comportamiento complejo de pines, incluyendo KWS

En el caso de circuitos con un comportamiento complejo de pines, como los circuitos con motor host y/o KWS, el controlador debe deshabilitar ACX para evitar el manejo de puentes de flujo, y en su lugar, crear un puente de flujo sin inmode. Este enfoque impedirá que ACX asocie automáticamente secuencias a puentes de transmisión.

Consulte también

Activación por voz