Plusieurs assistants vocaux

La plateforme Multiple Voice Assistant permet de prendre en charge des assistants vocaux supplémentaires dans Windows. Cela permet à d’autres assistants d’être disponibles sur les appareils Windows tels que les PC et les appareils portables comme HoloLens. Plusieurs assistants vocaux peuvent être actifs sur le même appareil en utilisant un ensemble de motifs de mots clés pris en charge.

Pour des informations sur la mise en œuvre de Windows Cortana, veuillez consulter la section Activation vocale.

Activation vocale

L’activation vocale est une fonctionnalité qui permet aux utilisateurs d’invoquer un moteur de reconnaissance vocale à partir de divers états d’alimentation de l’appareil en prononçant une phrase spécifique.

La mise en œuvre de l’activation vocale est un projet important et une tâche réalisée par les fournisseurs de SoC. Les OEM peuvent contacter leur fournisseur de SoC pour obtenir des informations sur l’implémentation de l’activation vocale de leur SoC.

L’activation vocale permet aux utilisateurs d’accéder rapidement à l’expérience de l’assistant vocal en dehors de leur contexte actif (c’est-à-dire ce qui est actuellement à l’écran) en utilisant 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 de Xbox, cela peut être parce qu’il ne veut pas trouver et connecter une manette. Pour les utilisateurs de PC, ils peuvent vouloir accéder rapidement à une expérience sans avoir à effectuer plusieurs actions de souris, de tactile et/ou de clavier, comme dans le cas d’un ordinateur dans la cuisine.

L’activation vocale est alimentée par un détecteur de mot-clé (KWS) qui réagit si la phrase-clé est détectée. Les phrases clés peuvent inclure des mots clés tels que « Hey Contoso ». Détection de mots clés décrit la détection du mot clé par le matériel ou le logiciel.

Les phrases clés peuvent être prononcées seules (« Hey Contoso ») comme une commande en deux temps, ou suivies d’une action vocale formant une commande enchaînée (« Hey Contoso, quel est mon prochain rendez-vous ? »).

Microsoft fournit un détecteur de mots clés par défaut dans le système d’exploitation (détecteur de mots clés logiciel) pour offrir une expérience d’assistant vocal dans les cas où la détection de mots clés matérielle 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 une détection de mots clés en deux étapes. Pour plus d’informations, contactez AskMVA@Microsoft.com.

Si le détecteur de mots clés doit réveiller l’appareil à partir d’un état de faible consommation, la solution est connue sous le nom de Wake-on-Voice (WoV). Pour plus d’informations, consultez la section Wake on Voice plus loin dans cet article.

Glossaire des termes

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

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

Pour implémenter un détecteur de mot-clé matériel (HW KWS), les fournisseurs de SoC doivent accomplir les tâches suivantes.

• Créer un détecteur de mot-clé personnalisé basé sur l’échantillon SYSVAD décrit plus loin dans ce sujet. Vous mettrez en œuvre ces méthodes dans une DLL COM, décrite dans Interface de l’adaptateur OEM du détecteur d’événements.
• Implémenter les améliorations WAVE RT décrites dans Améliorations WAVERT.
• Fournir des entrées de fichier INF pour décrire tous les APO personnalisés utilisés pour la détection de mot-clé.
  • 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
• Examinez les recommandations matérielles et les directives de test dans Recommandations pour les appareils audio. Cette rubrique fournit des conseils et des recommandations pour la conception et le développement de dispositifs d’entrée audio destinés à être utilisés avec la plateforme de reconnaissance vocale de Microsoft.
• Supporter à la fois les commandes par étapes et enchaînées.
• Respecter les exigences locales des assistants vocaux
• Les APO (objets de traitement audio) doivent fournir les effets suivants :
  • AEC
  • AGC
  • NS
• Les effets pour le mode de traitement vocal doivent être rapportés par l’APO MFX.
• L’APO peut effectuer la conversion de format en tant que MFX.
• L’APO doit sortir le format suivant :
  • 16 kHz, mono, FLOAT.
• Concevez éventuellement des APO personnalisés 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 l’état de fonctionnement S0 et l’état de veille S0 également connu sous le nom de veille moderne.
• HW KWS WoV n’est pas pris en charge depuis S3.

AEC

L’annulation d’écho acoustique (AEC) peut être effectuée par le DSP au moment où l’audio éclate est capturé, ou elle peut être effectuée ultérieurement via un APO logiciel. Pour effectuer une AEC logicielle avec les données d’éclatement de KWS, il est nécessaire d’avoir l’audio de boucle correspondante au moment où les données d’éclatement ont été capturées. Pour ce faire, un format audio personnalisé pour la sortie d’éclatement a été créé, qui entrelace l’audio de boucle dans les données audio d’éclatement.

À partir de la version 20H1 de Windows, l’APO AEC de Microsoft est conscient de ce format entrelacé et peut l’utiliser pour effectuer l’AEC. Pour plus d’informations, consultez la section KSPROPERTY_INTERLEAVEDAUDIO_FORMATINFORMATION.

Validation

Validez la prise en charge matérielle des propriétés KSPROPSETID_SoundDetector2 avec les tests Voice Activation Manager 2.

Aperçu du code d’exemple

Il y a un code d’exemple pour un pilote audio qui implémente l’activation vocale sur GitHub dans le cadre de l’échantillon de l’adaptateur audio virtuel SYSVAD. Il est recommandé d’utiliser ce code comme point de départ.

Pour plus d’informations sur le pilote audio d’exemple SYSVAD, veuillez consulter la rubrique Pilotes audio d’exemple.

Informations sur le 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 de pilote de périphérique du détecteur d’événements est responsable de la configuration et de l’armement du détecteur de mots clés matériel (KWS). Elle est également utilisée par le pilote pour notifier le système d’un événement de détection.
• DLL de l’adaptateur OEM du détecteur d’événements. Cette DLL implémente une interface COM pour adapter les données opaques spécifiques au pilote pour être utilisées par l’OS pour aider à la détection de mot-clé.
• Améliorations WaveRT. Les améliorations permettent au pilote audio de diffuser en rafale les données audio mises en tampon à partir de la détection de mot-clé.

Propriétés du point de terminaison audio

La construction du graphe de point de terminaison audio se fait normalement. Le graphe est préparé pour gérer la capture plus rapide que le temps réel. Les horodatages sur les tampons capturés restent vrais. Plus précisément, les horodatages refléteront correctement les données capturées dans le passé et mises en tampon, et qui sont maintenant « en rafale ».

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 une KSPROPERTY et l’ID d’événement pour armer, réinitialiser, détecter, etc., le mot clé.

• 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 une liste de GUID qui identifient les types de modèles pris en charge.
• Armé : KSPROPERTY_SOUNDDETECTOR_ARMED. Cette propriété de lecture/écriture est un simple statut booléen indiquant si le détecteur est armé. L’OS définit cela pour engager le détecteur de mot-clé. L’OS peut l’effacer pour désactiver. Le pilote efface automatiquement cela lorsque les modèles de mots-clés sont définis et également après qu’un mot-clé a été détecté. (L’OS doit réarmer).
• Résultat de la correspondance : KSPROPERTY_SOUNDDETECTOR_RESET est utilisé pour réinitialiser le détecteur de son au démarrage.

Lors de la détection d’un mot clé, une notification PNP contenant KSNOTIFICATIONID_SoundDetector est envoyée. REMARQUE : il ne s’agit pas d’un KSEvent, mais d’un événement PNP qui est 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érations

Démarrage du système

1. Le système d’exploitation envoie une KSPROPERTY_SOUNDDETECTOR_RESET pour effacer tout état précédent du détecteur, réinitialisant tous les détecteurs à désarmé et effaçant les motifs précédemment 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 OEM du détecteur d’événements pour récupérer la liste des mots clés et langues pris en charge.
4. Le système d’exploitation s’inscrit pour recevoir des notifications PNP personnalisées envoyées par le pilote.
5. Le système d’exploitation définit le ou les motifs de mots clés requis.
6. Le système d’exploitation arme le ou les détecteurs.

Opération interne du pilote et du matériel

Pendant que le détecteur est armé, le matériel peut capturer et mettre en tampon en continu les données audio dans un petit tampon FIFO. (La taille de ce tampon FIFO est déterminée par des exigences en dehors de ce document, mais peut généralement être de quelques centaines de millisecondes à plusieurs secondes.) L’algorithme de détection fonctionne sur les données circulant dans ce tampon. La conception du pilote et du matériel est telle que, lorsqu’il est armé, il n’y a aucune interaction entre le pilote et le matériel et aucune interruption des processeurs « application » jusqu’à ce qu’un mot clé soit détecté. Cela permet au système d’atteindre un état de basse consommation s’il n’y a pas d’autre activité.

Lorsque le matériel détecte un mot-clé, il génère une interruption. En attendant que le pilote traite l’interruption, le matériel continue de capturer l’audio dans le tampon, garantissant ainsi qu’aucune donnée après le mot-clé ne soit perdue, dans les limites du 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 tout le mot clé prononcé, y compris 1,6s 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/fin des mots-clés, le logiciel DSP peut avoir besoin d’horodater les événements en interne en fonction d’une 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 mapper les horodatages DSP à une valeur de compteur de performance Windows. La méthode pour ce faire est spécifique à la conception matérielle. Une solution possible est que le pilote lise le compteur de performance actuel, interroge l’horodatage DSP actuel, lise à nouveau le compteur de performance actuel, puis estime une corrélation entre le compteur de performance et le temps DSP. Ensuite, étant donné la corrélation, le pilote peut mapper les horodatages DSP des mots-clés aux horodatages des compteurs de performance Windows.

Interface de l’adaptateur OEM du détecteur d’événements

L’OEM fournit une implémentation d’objet COM qui agit comme un intermédiaire entre le système d’exploitation et le pilote, aidant à calculer ou à analyser les données opaques qui sont écrites et lues par le pilote audio via les propriétés 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 du type de motif pour instancier l’objet COM approprié compatible avec le type de motif de mot clé et appelle les méthodes de l’interface IEventDetectorOemAdapter de l’objet.

Exigences du modèle de threading COM

La mise en œuvre de l’OEM peut choisir n’importe lequel des modèles de threading 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 devrait pas nécessiter de stocker un é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 WAVERT

Les interfaces miniport sont définies pour être implémentées par les pilotes miniport WaveRT. Ces interfaces fournissent des méthodes pour soit simplifier le pilote audio, améliorer les performances et la fiabilité du pipeline audio du système d’exploitation, soit prendre en charge de nouveaux scénarios. Une propriété d’interface de périphérique PnP est définie permettant au pilote de fournir une expression statique de ses contraintes de taille de tampon au système d’exploitation.

Tailles de tampon

Un pilote fonctionne sous diverses contraintes lorsqu’il déplace des 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 aux modules de traitement du signal dans le matériel ou le DSP associé.

Les solutions HW-KWS doivent prendre en charge des tailles de capture audio d’au moins 100 ms et jusqu’à 200 ms.

Le pilote exprime les contraintes de taille de tampon en définissant la propriété de périphérique DEVPKEY_KsAudio_PacketSize_Constraints2 sur l’interface de périphérique PnP KSCATEGORY_AUDIO du filtre KS qui a les broches de streaming KS. Cette propriété doit rester valide et stable tant que l’interface du 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 la propriété DEVPKEY_KsAudio_PacketSize_Constraints2 contient une structure KSAUDIO_PACKETSIZE_CONSTRAINTS2 décrivant les contraintes matérielles physiques (c’est-à-dire en raison de la mécanique de transfert des données du 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 vers le système d’exploitation. Si cette interface est disponible sur un flux de capture, le système d’exploitation utilise les méthodes de cette interface pour accéder aux données dans le tampon WaveRT. Pour plus d’informations, veuillez consulter la section IMiniportWaveRTInputStream::GetReadPacket.

IMiniportWaveRTOutputStream

Un miniport WaveRT implémente facultativement cette interface pour être informé des progrès d’écriture du système d’exploitation et pour retourner la position précise du flux. Pour plus d’informations, consultez IMiniportWaveRTOutputStream::SetWritePacket, IMiniportWaveRTOutputStream::GetOutputStreamPresentationPosition et IMiniportWaveRTOutputStream::GetPacketCount.

Horodatages du compteur de performance

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

Dans les appareils qui ont des pipelines DSP complexes et du traitement de signal, calculer un horodatage précis peut être difficile et doit être fait avec soin. Les horodatages ne doivent pas simplement refléter le moment où les é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 le DSP, calculez une corrélation entre le compteur de performance Windows et l’horloge murale du DSP. Les procédures pour cela peuvent varier de très simples (mais moins précises) à assez complexes ou novatrices (mais plus précises).
• Tenez compte de tout retard constant dû aux algorithmes de traitement du signal ou au pipeline ou aux transports matériels, à moins que ces retards ne soient autrement pris en compte.

Opération de lecture en mode rafale

Cette section décrit l’interaction entre le système d’exploitation et le pilote pour les lectures en mode 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 de streaming basé sur les paquets WaveRT, y compris la fonction IMiniportWaveRTInputStream::GetReadPacket.

Deux exemples de scénarios de lecture en rafale sont discuté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 optionnellement mettre en tampon des données en interne en dehors du tampon WaveRT si le système d’exploitation ne lit pas les données assez rapidement en appelant IMiniportWaveRTInputStream::GetReadPacket.

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

1. Après la transition du flux vers KSSTATE_RUN, le pilote définit immédiatement l’événement de notification de tampon car il a déjà des données disponibles.

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

   a. Le pilote renvoie 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 le tampon WaveRT ainsi que la position du paquet par rapport au début du flux.

   b. Le pilote renvoie également la valeur du compteur de performance qui correspond à l’instant d’échantillonnage du premier échantillon du paquet. Notez que cette valeur du compteur de performance peut être relativement ancienne, en fonction de la quantité de données capturées mises en tampon dans le matériel ou le pilote (en dehors du tampon WaveRT).

   c. 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 du 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 du tampon avant de retourner de cette routine. Ou, ii. Programme le matériel pour mettre en rafale le paquet suivant dans l’espace disponible du tampon WaveRT, retourne false pour MoreData et définit ultérieurement l’événement de tampon lorsque le transfert est terminé.

3. Le système d’exploitation lit les données du tampon WaveRT en utilisant les informations retournées par GetReadPacket().

4. Le système d’exploitation attend le prochain événement de notification de tampon. L’attente peut se terminer immédiatement si le pilote a défini l’événement de 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 après avoir transféré plus de données capturées dans le tampon WaveRT et les a mises à disposition pour que le système d’exploitation les 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 sur la broche avant que le tampon ne déborde, alors le pilote peut terminer l’activité de mise en tampon interne et libérer les ressources associées.

Wake on Voice

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

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

La pile audio est responsable de la communication des données de réveil (ID du haut-parleur, déclencheur de mot clé, informations contextuelles sur le niveau de confiance) ainsi que de la notification aux clients intéressé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

Audio Class eXtension (ACX) définit une extension de classe Windows Driver Framework (WDF) pour le domaine audio. Pour plus d’informations sur ACX, consultez Vue d’ensemble des extensions de classe audio ACX et Résumé des objets ACX. Cette section décrit comment implémenter MVA en utilisant ACX.

ACX utilise la même infrastructure KS pour le détecteur de mots clés, ajoutant une couche d’abstraction pour simplifier la mise en œuvre 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 tous deux l’interface IEventDetectorOEMAdapter, et il n’y a aucune différence de mise en œuvre entre les deux pour l’adaptateur OEM.

La fonction AcxKeywordSpotterCreate est utilisée pour créer un objet opaque ACX keyword spotter (ACXKEYWORDSPOTTER) qui sera associé à un objet parent de l’appareil de circuit.

L’objet ACXKEYWORDSPOTTER est utilisé pour remplacer tous les appels KSPROPERTY_SOUNDDETECTOR, simplifiant la mise en œuvre de KWS. Il est utilisé dans le processus d’ajout d’un élément KWS et d’une broche KWS au circuit ACX. Les rappels associés prennent en charge l’obtention des motifs, l’armement, le désarmement et la réinitialisation. Il utilise une structure initialisée ACX_KEYWORDSPOTTER_CONFIG qui décrit la configuration du détecteur de mots clés.

La structure ACX_KEYWORDSPOTTER_CONFIG prend une structure ACX_KEYWORDSPOTTER_CALLBACKS qui définit les rappels suivants.

EvtAcxKeywordSpotterRetrieveArm : Le rappel ACX_KEYWORDSPOTTER_RETRIEVE_ARM.

EvtAcxKeywordSpotterAssignArm : Le rappel ACX_KEYWORDSPOTTER_ASSIGN_ARM.

EvtAcxKeywordSpotterAssignPatterns : Le rappel ACX_KEYWORDSPOTTER_ASSIGN_PATTERNS.

EvtAcxKeywordSpotterAssignReset : Le rappel ACX_KEYWORDSPOTTER_ASSIGN_RESET.

Événement PNP ACX

L’événement PNP ACX remplace KSNOTIFICATIONID_SoundDetector, simplifiant 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 rappels, des éléments de mots clés 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 détecteur de mots clés ACX et l’associer à un circuit existant.

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

Ensuite, le contexte du détecteur de mots clés est déterminé et utilisé pour créer le KeywordDetector 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 qui est ajoutée au contexte est fournie uniquement comme une implémentation d’exemple qui simule la détection de mots clés dans le pilote d’exemple. La classe CKeywordDetector ne fait pas partie du cadre ACX ni d’une partie requise de la mise en œuvre de MVA sur ACX, mais peut constituer un bon point de départ pour le développement d’un détecteur de mots clés réel.

Enfin, l’événement PnP ACX 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 un comportement de broche complexe, y compris KWS

Pour les circuits avec un comportement de broche complexe, tels que les circuits avec un moteur hôte et/ou KWS, le pilote doit désactiver ACX pour effectuer la gestion du pont de flux et, à la place, créer un pont de flux sans inmode. Cette approche empêchera ACX d’associer automatiquement des flux aux ponts de flux.

Voir aussi

Activation vocale