Assistant vocal à commandes multiples

La plateforme Assistant vocal multiple prend en charge d’autres assistants vocaux dans Windows. Cela permet à d’autres assistants d’être disponibles sur des appareils Windows tels que des PC et des appareils portables tels que HoloLens. Plusieurs assistants vocaux peuvent être actifs sur le même appareil à l’aide d’un ensemble de modèles de mots clés pris en charge.

Pour plus d’informations sur l’implémentation de Windows Cortana, consultez Activation vocale.

Activation vocale

L’activation vocale est une fonctionnalité qui permet aux utilisateurs d’appeler un moteur de reconnaissance vocale à partir de différents états d’alimentation d’appareil en disant une expression spécifique.

L’implémentation de l’activation vocale est un projet important et est une tâche effectuée par les fournisseurs soC. Les oem peuvent contacter leur fournisseur soC pour plus d’informations sur l’implémentation de l’activation vocale de leur soC.

L’activation vocale permet aux utilisateurs d’engager rapidement l’expérience de l’assistant vocal en dehors de leur contexte actif (c’est-à-dire ce qui est actuellement à l’écran) à l’aide de leur voix. Les utilisateurs souhaitent souvent pouvoir accéder instantanément à une expérience sans avoir à interagir physiquement avec ou à toucher un appareil. Pour un utilisateur Xbox, cela peut être de ne pas vouloir rechercher et connecter un contrôleur. Pour les utilisateurs de PC, ils peuvent souhaiter un accès rapide à une expérience sans avoir à effectuer plusieurs actions de souris, tactiles et/ou clavier, comme dans le cas d’un ordinateur dans la cuisine.

L’activation vocale est alimentée par un spotter de mots clés (KWS) qui réagit si l’expression clé est détectée. Les expressions clés peuvent inclure des mots clés tels que « Hey Contoso ». La détection de mot clé décrit la détection du mot clé par matériel ou logiciel.

Les expressions clés peuvent être prononcées par eux-mêmes (« Hey Contoso ») en tant que commande intermédiaire, ou suivie d’une action vocale qui compose une commande chaînée (« Hey Contoso, où est ma prochaine réunion ? »)

Microsoft fournit un détecteur de mots clé par défaut du système d’exploitation (détecteur de mots clé logiciel) pour offrir une expérience d’assistant vocal dans les cas où la détection de mots clé matériel n’est pas disponible. Bien que cela soit actuellement disponible pour Cortana, une configuration Microsoft supplémentaire peut être nécessaire pour intégrer d’autres assistants vocaux pour effectuer la détection de mots clés en deux étapes. Pour plus d’informations, contactez AskMVA@Microsoft.com.

Si le rôle de KWS est de réveiller l’appareil à partir d’un état basse consommation, la solution est appelée Wake-on-Voice (WoV). Pour plus d’informations, consultez Wake on Voice plus loin dans cet article.

Glossaire des termes

Ce glossaire récapitule les termes liés à l’activation vocale.

Intégration d’un détecteur de mots-clés matériel

Pour implémenter un spotter de mot clé matériel (HW KWS) les fournisseurs soC doivent effectuer les tâches suivantes.

• Créez un détecteur de mots clés personnalisé basé sur l’exemple SYSVAD décrit plus loin dans cette rubrique. Vous allez implémenter ces méthodes dans une DLL COM, décrite dans iEvent Detector OEM Adapter Interface.
• Implémenter les améliorations WAVE RT décrites dans Améliorations WAVERT.
• Fournissez des entrées de fichier INF pour décrire les API personnalisées utilisées pour la détection de mots clés.
  • 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
• Passez en revue les recommandations matérielles et les conseils de test dans les sections Recommandations pour les appareils audio. Cette rubrique fournit des conseils et des recommandations pour la conception et le développement d’appareils d’entrée audio destinés à être utilisés avec la plateforme Speech de Microsoft.
• Supporter à la fois les commandes par étapes et enchaînées.
• Répondre aux exigences de paramètres régionaux des assistants vocaux
• Les API (objets de traitement audio) doivent fournir les effets suivants :
  • AEC
  • AGC
  • NS
• Les effets du mode de traitement speech doivent être signalés par l’APO MFX.
• L’APO peut effectuer la conversion de format en tant que MFX.
• L’APO doit générer le format suivant :
  • 16 kHz, mono, FLOAT.
• Concevez éventuellement toutes les API personnalisées pour améliorer le processus de capture audio. Pour plus d’informations, veuillez consulter la section Objets de traitement audio Windows.

Exigences WoV pour les détecteurs de mot-clé déportés sur le matériel (HW KWS)

• HW KWS WoV est pris en charge pendant le mode de fonctionnement S0 et le mode de veille S0, également appelé Veille Moderne.
• HW KWS WoV n’est pas pris en charge à partir de S3.

AEC

AEC peut être réalisé par le DSP au moment où l’audio en rafale est capturé, ou ultérieurement par une APO logicielle. Pour effectuer un AEC logiciel avec des données de rafale KWS, il est nécessaire d’avoir l’audio de bouclage correspondant à partir du moment où les données de rafale ont été capturées. Pour ce faire, un format audio personnalisé pour la sortie en rafale a été créé, qui entrelace l'audio de boucle dans les données audio en rafale.

À partir de Windows version 20H1, Microsoft AEC APO prend en compte ce format entrelacé et peut l’utiliser pour effectuer l’AEC. Pour obtenir plus d’informations, consultez KSPROPERTY_INTERLEAVEDAUDIO_FORMATINFORMATION.

Vérification

Validez la prise en charge de HW pour les propriétés KSPROPSETID_SoundDetector2 avec les tests Voice Activation Manager 2.

Vue d’ensemble de l’exemple de code

Il existe un exemple de code pour un pilote audio qui implémente l’activation vocale sur GitHub dans le cadre de l’exemple de carte audio virtuelle SYSVAD. Il est recommandé d’utiliser ce code comme point de départ.

Pour plus d’informations sur l’exemple de pilote audio SYSVAD, consultez Exemple de pilotes audio.

Informations système de reconnaissance de mot clé

Support de la pile audio pour l’activation vocale

Les interfaces externes de la pile audio pour activer l’activation vocale servent de pipeline de communication pour la plateforme de reconnaissance vocale et les pilotes audio. Les interfaces externes sont divisées en trois parties.

• Interface de pilote de périphérique du détecteur d’événements (DDI) L’interface du pilote de périphérique détecteur d’événements est chargée de configurer et d’armer le détecteur de mots clés HW (KWS). Il est également utilisé par le pilote pour notifier le système d’un événement de détection.
• DLL de l’adaptateur OEM IEvent Detector. Cette DLL implémente une interface COM pour adapter les données opaques spécifiques du pilote à utiliser par le système d’exploitation pour faciliter la détection des mots clés.
• Améliorations de WaveRT. Les améliorations permettent au pilote audio de diffuser en continu les données audio mises en mémoire tampon à partir de la détection de mots clés.

Propriétés du point de terminaison audio

La génération de graphe de point de terminaison audio se produit normalement. Le graphe est préparé pour gérer la capture plus rapide que le temps réel. Les horodatages sur les mémoires tampons capturées restent inchangés. Plus précisément, les horodatages reflètent correctement les données capturées dans le passé et mises en mémoire tampon, qui sont maintenant en train de se déverser.

Théorie du streaming audio en contournant le Bluetooth

Le pilote expose un filtre KS pour son périphérique de capture comme d’habitude. Ce filtre prend en charge plusieurs propriétés KS et un événement KS pour configurer, activer et signaler un événement de détection. Le filtre comprend également une usine de broches supplémentaire identifiée comme une broche de détecteur de mot-clé (KWS). Cette broche est utilisée pour diffuser l’audio à partir du détecteur de mot-clé.

La propriété est : KSPROPSETID_SoundDetector2

Toutes les propriétés KSPROPSETID_SoundDetector2 sont appelées avec une structure de données KSSOUNDDETECTORPROPERTY . Cette structure de données contient un KSPROPERTY et l’ID d’événement pour que le mot clé soit armé, réinitialisé, détecté, etc.

• Types de mots-clés pris en charge : KSPROPERTY_SOUNDDETECTOR_PATTERNS. Cette propriété est définie par le système d’exploitation pour configurer les mots clés à détecter.
• Liste des GUID des modèles de mots-clés : KSPROPERTY_SOUNDDETECTOR_SUPPORTEDPATTERNS. Cette propriété est utilisée pour obtenir la liste des GUID qui identifient les types de modèles pris en charge.
• Armé : KSPROPERTY_SOUNDDETECTOR_ARMED. Cette propriété en lecture/écriture est simplement un état booléen indiquant si le détecteur est armé. Le système d’exploitation définit ceci pour engager le détecteur de mots clés. Le système d'exploitation peut effacer ceci pour désactiver. Le pilote efface automatiquement cela lorsque les modèles de mots clés sont définis et une fois qu’un mot clé est détecté. (L’OS doit réarmer).
• Résultat de correspondance : KSPROPERTY_SOUNDDETECTOR_RESET est utilisé pour réinitialiser le détecteur de son au moment du démarrage.

Au moment de la détection de mot clé, une notification PNP contenant KSNOTIFICATIONID_SoundDetector est envoyée. REMARQUE : ce n’est pas un KSEvent, mais plutôt un événement PNP envoyé, avec une charge utile, via IoReportTargetDeviceChangeAsynchronous.

KSNOTIFICATIONID_SoundDetector est défini dans ksmedia.h, comme indiqué ici.

// 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)

Séquence d’opération

Démarrage du système

1. Le système d’exploitation envoie une KSPROPERTY_SOUNDDETECTOR_RESET pour effacer tout état de détecteur précédent, réinitialisant tous les détecteurs pour désarmer et effacer les modèles précédents définis.
2. Le système d’exploitation interroge KSPROPERTY_SOUNDDETECTOR_PATTERNS pour récupérer le clsid pour l’adaptateur OEM du détecteur d’événements.
3. Le système d’exploitation utilise l’adaptateur détecteur d’événements OEM pour récupérer la liste des mots-clés et des langues prises en charge.
4. Le système d'exploitation s'enregistre pour recevoir les notifications PNP personnalisées envoyées par le pilote.
5. Le système d’exploitation définit le ou les modèles de mots clés requis.
6. Le système d'exploitation active le ou les détecteurs

Opération interne du pilote et du matériel

Bien que le détecteur soit armé, le matériel peut capturer et mettre en mémoire tampon en continu des données audio dans une petite mémoire tampon FIFO. (La taille de cette mémoire tampon FIFO est déterminée par les exigences en dehors de ce document, mais peut généralement être des centaines de millisecondes à plusieurs secondes.) L’algorithme de détection fonctionne sur le streaming des données via cette mémoire tampon. La conception du pilote et du matériel est telle que, lorsqu'ils sont armés, il n’y a pas d’interaction entre le pilote et le matériel, et aucune interruption des processeurs « application » n’a lieu jusqu’à la détection d’un mot clé. Cela permet au système d’atteindre un état d’alimentation inférieur s’il n’existe aucune autre activité.

Lorsque le matériel détecte un mot clé, il génère une interruption. En attendant que le pilote puisse traiter l’interruption, le matériel continue de capturer l’audio dans la mémoire tampon, ce qui garantit qu’aucune donnée après la perte du mot clé est perdue, dans les limites de mise en mémoire tampon.

Horodatages des mots-clés

Après avoir détecté un mot clé, toutes les solutions d’activation vocale doivent mettre en mémoire tampon le mot clé parlé entier, y compris 1,6 secondes avant le début du mot clé. Le pilote audio doit fournir des horodatages identifiant le début et la fin de la phrase clé dans le flux.

Pour prendre en charge les horodatages de début et de fin de mot clé, le logiciel DSP peut avoir besoin de dater en interne les événements en fonction de l'horloge DSP. Une fois qu’un mot clé est détecté, le logiciel DSP interagit avec le pilote pour préparer un événement KS. Le pilote et le logiciel DSP devront associer les horodatages DSP à une valeur de compteur de performances Windows. La méthode de cette opération est spécifique à la conception matérielle. Une solution possible consiste à permettre au pilote de lire le compteur de performances actuel, d’interroger l’horodatage DSP actuel, de lire à nouveau le compteur de performances actuel, puis d’estimer une corrélation entre le compteur de performances et le temps DSP. Ensuite, grâce à la corrélation, le pilote peut associer les horodatages DSP du mot-clé aux horodatages du compteur de performances Windows.

Interface de l’adaptateur OEM IEvent Detector

L’OEM fournit une implémentation d’objet COM qui agit comme intermédiaire entre le système d’exploitation et le pilote, ce qui permet de calculer ou d’analyser les données opaques écrites et lues dans le pilote audio via KSPROPERTY_SOUNDDETECTOR_PATTERNS et KSPROPERTY_SOUNDDETECTOR_MATCHRESULT.

Le CLSID de l’objet COM est un GUID de type de modèle de détecteur renvoyé par la propriété KSPROPERTY_SOUNDDETECTOR_SUPPORTEDPATTERNS. Le système d’exploitation appelle CoCreateInstance en passant le GUID de type de modèle pour instancier l’objet COM approprié compatible avec le type de modèle de mot clé et appelle des méthodes sur l’interface IEventDetectorOemAdapter de l’objet.

Exigences du modèle de threading COM

L’implémentation d’OEM peut choisir l’un des modèles de thread COM.

IEventDetectorOemAdapter

La conception de l’interface tente de maintenir l’implémentation de l’objet sans état. En d’autres termes, l’implémentation ne doit pas nécessiter de stockage d’état entre les appels de méthode. En fait, les classes C++ internes n’ont probablement pas besoin de variables membres au-delà de celles requises pour implémenter un objet COM en général.

Méthodes

Implémentez les méthodes suivantes.

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

Améliorations apportées à WAVERT

Les interfaces miniport sont définies pour être implémentées par les pilotes miniport WaveRT. Ces interfaces fournissent des méthodes pour simplifier le pilote audio, améliorer les performances et la fiabilité du pipeline audio du système d’exploitation, ou prendre en charge de nouveaux scénarios. Une propriété d’interface d’appareil PnP est définie, ce qui permet au pilote de fournir des expressions statiques de ses contraintes de taille de mémoire tampon au système d’exploitation.

Tailles de tampon

Un pilote fonctionne sous différentes contraintes lors du déplacement de données audio entre le système d’exploitation, le pilote et le matériel. Ces contraintes peuvent être dues au transport matériel physique qui déplace les données entre la mémoire et le matériel, et/ou en raison des modules de traitement de signal au sein du matériel ou du DSP associé.

Les solutions HW-KWS doivent prendre en charge une taille de capture audio d'au moins 100 ms et jusqu'à 200 ms.

Le pilote exprime les contraintes de taille de mémoire tampon en définissant la propriété de l’appareil DEVPKEY_KsAudio_PacketSize_Constraints2 sur l’interface de périphérique pnP KSCATEGORY_AUDIO du filtre KS qui a les broches de diffusion en continu KS. Cette propriété doit rester valide et stable pendant que l’interface de filtre KS est activée. Le système d’exploitation peut lire cette valeur à tout moment sans avoir à ouvrir un handle vers le pilote et appeler le pilote.

DEVPKEY_KsAudio_PacketSize_Constraints2

La valeur de propriété DEVPKEY_KsAudio_PacketSize_Constraints2 contient une structure KSAUDIO_PACKETSIZE_CONSTRAINTS2 décrivant les contraintes matérielles physiques (par exemple, en raison de la mécanique du transfert de données de la mémoire tampon WaveRT vers le matériel audio). La structure comprend un tableau de 0 ou plus de structures KSAUDIO_PACKETSIZE_PROCESSINGMODE_CONSTRAINT décrivant les contraintes spécifiques à tout mode de traitement du signal. Le pilote définit cette propriété avant d’appeler PcRegisterSubdevice ou d’activer autrement son interface de filtre KS pour ses broches de streaming.

IMiniportWaveRTInputStream

Un pilote implémente cette interface pour une meilleure coordination du flux de données audio du pilote au système d’exploitation. Si cette interface est disponible sur un flux de capture, le système d’exploitation utilise des méthodes sur cette interface pour accéder aux données dans la mémoire tampon WaveRT. Pour plus d’informations, consultez IMiniportWaveRTInputStream ::GetReadPacket

IMiniportWaveRTOutputStream

Un miniport WaveRT peut implémenter cette interface pour recevoir des notifications sur la progression de l’écriture à partir du système d’exploitation et fournir une position de flux précise. Pour plus d’informations, consultez IMiniportWaveRTOutputStream::SetWritePacket, IMiniportWaveRTOutputStream::GetOutputStreamPresentationPosition et IMiniportWaveRTOutputStream::GetPacketCount.

Horodatages du compteur de performance

Plusieurs routines de pilote retournent des horodatages du compteur de performances Windows reflétant l’heure à laquelle les échantillons sont capturés ou présentés par l’appareil.

Dans les appareils qui ont des pipelines DSP complexes et un traitement de signal, le calcul d’un horodatage précis peut être difficile et doit être effectué de manière réfléchie. Les horodatages ne doivent pas simplement refléter l’heure à laquelle des échantillons ont été transférés vers ou depuis le système d’exploitation vers le DSP.

• Dans le DSP, suivez les horodatages des échantillons à l’aide d’une horloge interne du DSP.
• Entre le pilote et DSP, calculez une corrélation entre le compteur de performances Windows et l’horloge murale DSP. Les procédures pour cela peuvent aller de très simples (mais moins précises) à assez complexes ou novatrices (mais plus précises).
• Tenez compte de tous les retards constants en raison des algorithmes de traitement de signal, des pipelines ou des transports matériels, sauf si ces retards sont autrement pris en compte.

Opération de lecture en rafale

Cette section décrit l’interaction du système d’exploitation et du pilote pour les lectures en rafale. La lecture en rafale peut se produire en dehors du scénario d’activation vocale tant que le pilote prend en charge le modèle WaveRT de streaming basé sur les paquets, y compris la fonction IMiniportWaveRTInputStream ::GetReadPacket.

Deux exemples de scénarios de lecture en rafale sont abordés. Dans un scénario, si le miniport prend en charge une broche ayant la catégorie de broche KSNODETYPE_AUDIO_KEYWORDDETECTOR, alors le pilote commencera à capturer et à mettre en tampon des données en interne lorsqu’un mot-clé est détecté. Dans un autre scénario, le pilote peut éventuellement mettre en mémoire tampon des données en interne en dehors de la mémoire tampon WaveRT si le système d’exploitation ne lit pas les données suffisamment rapidement en appelant IMiniportWaveRTInputStream ::GetReadPacket.

Pour les données en rafale capturées avant la transition vers KSSTATE_RUN, le pilote doit conserver des informations d’horodatage précises ainsi que les données de capture mises en mémoire tampon. Les horodatages identifient l’instantané d’échantillonnage des échantillons capturés.

1. Une fois que le flux passe à KSSTATE_RUN, le pilote définit immédiatement l’événement de notification de mémoire tampon, car il dispose déjà de données disponibles.

2. Sur cet événement, le système d’exploitation appelle GetReadPacket() pour obtenir des informations sur les données disponibles.

   a) Le pilote retourne le numéro de paquet des données capturées valides (0 pour le premier paquet après la transition de KSSTATE_STOP à KSSTATE_RUN), à partir duquel le système d’exploitation peut dériver la position du paquet dans la mémoire tampon WaveRT ainsi que la position du paquet par rapport au début du flux.

   b. Le pilote retourne également la valeur du compteur de performances qui correspond au moment d'échantillonnage du premier échantillon du paquet. Notez que cette valeur de compteur de performances peut être relativement ancienne, en fonction de la quantité de données de capture mises en mémoire tampon dans le matériel ou le pilote (en dehors de la mémoire tampon WaveRT).

   v. S’il y a plus de données mises en tampon non lues disponibles, le pilote soit : i. Transfère immédiatement ces données dans l’espace disponible de la mémoire tampon WaveRT (c’est-à-dire l’espace non utilisé par le paquet retourné par GetReadPacket), retourne true pour MoreData et définit l’événement de notification de mémoire tampon avant de revenir de cette routine. Ou, ii. Programme le matériel pour faire éclater le paquet suivant dans l’espace disponible de la mémoire tampon WaveRT, retourne false pour MoreData, puis définit l’événement de mémoire tampon une fois le transfert terminé.

3. Le système d’exploitation lit les données de la mémoire tampon WaveRT à l’aide des informations retournées par GetReadPacket().

4. Le système d’exploitation attend l’événement de notification de mémoire tampon suivant. L’attente peut se terminer immédiatement si le pilote définit la notification de mémoire tampon à l’étape (2c).

5. Si le pilote n’a pas immédiatement défini l’événement à l’étape (2c), le pilote définit l’événement une fois qu’il transfère plus de données capturées dans la mémoire tampon WaveRT et le rend disponible pour que le système d’exploitation lise

6. Revenez à (2).

Pour les broches de détecteur de mots-clés KSNODETYPE_AUDIO_KEYWORDDETECTOR, les pilotes doivent allouer suffisamment de tampon interne pour au moins 5000 ms de données audio. Si le système d’exploitation ne parvient pas à créer un flux de données sur la broche avant que la mémoire tampon ne déborde, le pilote peut mettre fin à l’activité de mise en mémoire tampon interne et libérer les ressources associées.

Réveil par la voix

Wake-on-Voice (WoV) permet à l’utilisateur d’activer et d’interroger un moteur de reconnaissance vocale à partir d’un état de faible puissance jusqu’à un état d’alimentation complet avec l’écran en disant un mot clé spécifique, tel que « Hey Contoso ».

Cette fonctionnalité permet à l’appareil d’être toujours à l’écoute de la voix de l’utilisateur pendant que l’appareil est inactif et que l’écran est désactivé. Cela est dû au mode d’écoute qui utilise beaucoup moins de puissance par rapport à l’enregistrement normal du microphone. WoV permet la commande vocale enchaînée comme « Hey Contoso, quel est mon prochain rendez-vous » pour obtenir une réponse d’un assistant vocal de manière mains libres.

La pile audio est chargée de communiquer les données de réveil (identifiant de l'orateur, déclencheur de mot-clé, informations contextuelles sur le niveau de confiance) et de notifier les clients concernés que le mot-clé a été détecté.

Validation sur les systèmes Modern Standby

WoV à partir d’un état inactif du système peut être validé sur les systèmes Modern Standby en utilisant les tests Modern Standby Wake on Voice Basic Test on AC-power Source et Modern Standby Wake on Voice Basic Test on DC-power Source dans le HLK. Ces tests vérifient que le système dispose d’un détecteur de mots-clés matériel (HW-KWS), est capable d’entrer dans l’état de plus basse consommation d’exécution (DRIPS) et est capable de se réveiller de Modern Standby sur commande vocale avec une latence de reprise système inférieure ou égale à une seconde.

ACX et MVA

La classe audio eXtension (ACX) définit une extension de classe WDF (Windows Driver Framework) pour le domaine audio. Pour plus d’informations sur ACX, consultez la vue d’ensemble des extensions de classe audio ACX et Résumé des objets ACX. Cette section explique comment implémenter MVA à l’aide d’ACX.

ACX utilise l'infrastructure KS identique pour le détecteur de mots clés, en ajoutant une couche d’abstraction afin de simplifier l’implémentation du pilote. Avec ACX, la même DLL OEM est utilisée comme décrit ci-dessus et reste inchangée. AcX et Portcls nécessitent l’interface IEventDetectorOEMAdapter, et il n’existe aucune différence dans l’implémentation entre les deux pour l’adaptateur OEM.

La fonction AcxKeywordSpotterCreate est utilisée pour créer un objet opaque ACX pour la détection de mots clés (ACXKEYWORDSPOTTER) qui sera associé à un objet parent de dispositif de circuit.

L’objet ACXKEYWORDSPOTTER est utilisé pour remplacer tous les appels KSPROPERTY_SOUNDDETECTOR, ce qui simplifie l’implémentation de KWS. Il est utilisé dans le processus d’ajout d’un élément KWS et d’une broche KWS au circuit ACX. Les callbacks associés s’occupent de l’obtention des modèles, de l'armement, du désarmement et de la réinitialisation. Il utilise une structure de ACX_KEYWORDSPOTTER_CONFIG initialisée qui décrit la configuration du spotter de mots clés.

La structure ACX_KEYWORDSPOTTER_CONFIG prend une structure ACX_KEYWORDSPOTTER_CALLBACKS, qui définit les fonctions de rappel suivantes.

EvtAcxKeywordSpotterRetrieveArm - Fonction de rappel ACX_KEYWORDSPOTTER_RETRIEVE_ARM.

EvtAcxKeywordSpotterAssignArm - Le rappel ACX_KEYWORDSPOTTER_ASSIGN_ARM.

EvtAcxKeywordSpotterAssignPatterns - Rappel ACX_KEYWORDSPOTTER_ASSIGN_PATTERNS .

EvtAcxKeywordSpotterAssignReset - Le callback ACX_KEYWORDSPOTTER_ASSIGN_RESET.

Événement ACX PNP

L’événement PNP ACX remplace KSNOTIFICATIONID_SoundDetector, ce qui simplifie l’événement de notification de détection. La fonction ACX_PNPEVENT_CONFIG_INIT initialise une structure ACX_PNPEVENT_CONFIG. Aucune entrée n’est utilisée avec cette fonction.

Exemple de code ACX KWS

L’exemple de code ACX KWS montre l’initialisation des fonctions de rappel (callbacks), des éléments de mot clé et la création du détecteur de mots-clés.

{
    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;

Ensuite, la fonction AcxKeywordSpotterCreate est utilisée pour créer l’objet spotter de mot clé ACX et l’associer à un circuit existant.

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

Puis, le contexte du détecteur de mots-clés est déterminé et utilisé pour créer le détecteur de mots-clés dans la mémoire 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;
    }

Dans cet exemple de code, la classe CKeywordDetector ajoutée au contexte est fournie uniquement en tant qu’exemple d’implémentation qui simule la détection de mots clés dans l’exemple de pilote. La classe CKeywordDetector ne fait pas partie de l'infrastructure ACX ni d'une partie requise pour l'implémentation de MVA sur ACX, mais elle peut fournir un bon point de départ pour le développement d'un détecteur de mots clés fonctionnel.

Enfin, l’événement ACX PnP est configuré et créé.

   
    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;

}

Circuits avec comportement de broche complexe, y compris KWS

Pour les circuits avec un comportement de broche complexe, tels que les circuits comportant un moteur hôte et/ou KWS, le pilote doit désactiver ACX pour empêcher la gestion du stream-bridge, et à la place, créer un stream-bridge sans mode interne. Cette approche empêchera ACX d’associer automatiquement des flux à des passerelles de flux.

Voir aussi

Activation vocale