Activation vocale

Cortana, la plateforme de reconnaissance vocale Windows, alimente toutes les expériences vocales dans Windows 10, telles que Cortana et la dictée. 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 : « Hey Cortana ». Pour créer du matériel prenant en charge la technologie d’activation vocale, passez en revue les informations contenues dans cet article.

Expérience utilisateur final Cortana

Pour comprendre l’expérience d’interaction vocale disponible dans Windows, consultez ces articles.

Présentation de l’activation vocale « Hey Cortana » et « Learn my voice »

Activation vocale « Hey Cortana »

La fonctionnalité d’activation vocale (VA) « Hey Cortana » permet aux utilisateurs d’engager rapidement l’expérience Cortana en dehors de leur contexte actif (autrement dit, 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 ou à toucher un appareil. Les utilisateurs de téléphone peuvent être en train de conduire et avoir leur attention et leurs mains occupées à conduire le véhicule. Un utilisateur Xbox peut ne pas vouloir rechercher et connecter un contrôleur. Les utilisateurs de PC peuvent souhaiter un accès rapide à une expérience sans avoir à effectuer plusieurs actions de souris, tactiles ou clavier. Par exemple, un ordinateur dans la cuisine utilisé lors de la cuisson.

L’activation vocale fournit une entrée vocale en écoute permanente via des phrases clés prédéfinies ou des phrases d’activation. Les expressions clés peuvent être énoncées par elles-mêmes (« Hey Cortana ») en tant que commande en deux étapes, ou suivies d’une action vocale, par exemple, « Hey Cortana, où est ma prochaine réunion ? », une commande enchaînée.

Le terme Détection de mot clé décrit la détection du mot clé par matériel ou logiciel.

L’activation Mot-clé seul se produit lorsque seul le mot-clé Cortana est dit, Cortana démarre et joue le son EarCon pour indiquer qu’il est en mode d’écoute.

Une commande chaînée décrit la possibilité d’émettre une commande immédiatement après le mot clé (comme « Hey Cortana, appeler John ») et de démarrer Cortana (s’il n’est pas déjà démarré) et de suivre la commande (en commençant un appel téléphonique avec John).

Ce diagramme illustre l'activation chaînée et uniquement par mots-clés.

Microsoft fournit un spotter de mots clés par défaut du système d’exploitation (spotter de mot clé logiciel) utilisé pour garantir la qualité des détections de mots clés matériels et fournir l’expérience Hey Cortana dans les cas où la détection de mot clé matériel est absente ou indisponible.

Fonctionnalité « Learn my voice »

La fonctionnalité « Learn my voice » permet à l’utilisateur d’entraîner Cortana à reconnaître sa voix unique. Pour ce faire, l’utilisateur sélectionne Découvrez comment je dis « Hey Cortana » dans l’écran des paramètres Cortana. L’utilisateur répète ensuite six expressions soigneusement choisies qui fournissent une variété suffisante de modèles phonétiques pour identifier les attributs uniques de la voix de l’utilisateur.

Lorsque l’activation vocale est associée à « Learn my voice », les deux algorithmes fonctionnent ensemble pour réduire les fausses activations. Cela est particulièrement utile pour le scénario de salle de réunion, où une personne dit « Hey Cortana » dans une salle pleine d’appareils. Cette fonctionnalité est disponible uniquement pour Windows 10 version 1903 et antérieure.

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. Si le KWS doit réveiller l’appareil à partir d’un état à faible alimentation, la solution est appelée Wake on Voice (WoV). Pour plus d’informations, consultez Wake on Voice.

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), effectuez les tâches suivantes.

• Créez un détecteur de mots clés personnalisé basé sur l’exemple SYSVAD décrit plus loin dans cet article. Vous allez implémenter ces méthodes dans une DLL COM, décrite dans l’interface d’adaptateur OEM détecteur de mots clés.
• 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. Cet article 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.
• Prenez en charge « Hey Cortana » pour chacun des paramètres régionaux Cortana pris en charge.
• 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 une conversion de format sous forme de 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.

Exigences AEC pour HW KWS

• Pour Windows version 1709

  • Pour prendre en charge HW KWS WoV pour l’état de veille S0 (Mode Veille Moderne), AEC n’est pas nécessaire.
  • HW KWS WoV pour le mode de veille S0 n’est pas pris en charge par Windows version 1709.

• Pour Windows version 1803

  • HW KWS WoV pour l’état de fonctionnement S0 est pris en charge.
  • Pour activer HW KWS WoV pour l’état de fonctionnement S0, l’APO doit prendre en charge l’AEC.

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. Le code est disponible à cet emplacement.

https://github.com/Microsoft/Windows-driver-samples/tree/main/audio/sysvad/

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 de détecteur de mot-clé (DDI). L’interface du pilote de périphérique détecteur de mots clés 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 d’adaptateur OEM de détecteur de mot-clé 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 streaming 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 qui ont été capturées dans le passé, mises en mémoire tampon, et se libèrent maintenant rapidement.

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 inclut également une autre usine de broches identifiée comme un détecteur de mots clés (KWS). Cette broche est utilisée pour diffuser l’audio à partir du détecteur de mot-clé.

Les propriétés sont les suivantes :

• Types de mots-clés pris en charge : KSPROPERTY_SOUNDDETECTOR_PATTERNS. Le système d’exploitation définit cette propriété 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 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_MATCHRESULT. Cette propriété de lecture contient les données de résultat après la détection.

L’événement déclenché lorsqu’un mot clé est détecté est un événement KSEVENT_SOUNDDETECTOR_MATCHDETECTED.

Séquence d’opération

Démarrage du système

1. Le système d’exploitation lit les types de mots clés pris en charge pour vérifier qu’il a des mots clés dans ce format.
2. Le système d’exploitation se registre à l’événement de changement d’état du détecteur.
3. Le système d’exploitation définit les modèles de mots clés.
4. Le système d'exploitation arme le détecteur.

À la réception de l’événement KS

1. Le conducteur désarme le détecteur.
2. Le système d’exploitation lit l’état du détecteur de mots clés, analyse les données retournées et détermine le modèle détecté.
3. Le système d’exploitation réarme le détecteur.

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, lorsque le système est armé, il n'y a aucune interaction entre le pilote et le matériel et aucune interruption des processeurs d'application jusqu'à ce qu'un mot-clé soit détecté. Cela permet au système d’atteindre un état d’alimentation inférieur 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 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 tous les mots clés parlés, y compris 250 ms 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 doivent 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 du détecteur de mots-clés

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 du type de modèle pour instancier l'objet COM approprié, qui est compatible avec le type de modèle de mot-clé, et appelle des méthodes sur l'interface IKeywordDetectorOemAdapter de cet objet.

Exigences du modèle de threading COM

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

IKeywordDetectorOemAdapter

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.

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

KEYWORDID

L’énumération KEYWORDID identifie le texte ou la fonction d'un mot-clé et est également utilisée dans les adaptateurs du service biométrique Windows. Pour plus d’informations, consultez Vue d’ensemble de l’infrastructure biométrique - Core Platform Components

typedef enum  {
  KwInvalid    = 0,
  KwHeyCortana = 1,
  KwSelect     = 2
} KEYWORDID;

Sélecteur de mots-clés

Le KEYWORDSELECTOR struct est un ensemble d’ID qui sélectionnent de manière unique un mot clé et un langage particuliers.

typedef struct
{
    KEYWORDID KeywordId;
    LANGID LangId;
} KEYWORDSELECTOR;

Gestion des données de modèle

modèle indépendant de l’utilisateur statique : la DLL OEM inclurait généralement des données de modèle indépendants de l’utilisateur statique intégrées à la DLL ou dans un fichier de données distinct inclus dans la DLL. L’ensemble des ID de mot clé pris en charge retournés par la routine GetCapabilities dépend de ces données. Par exemple, si la liste des ID de mot clé pris en charge retournés par GetCapabilities inclut KwHeyCortana, les données de modèle indépendant de l’utilisateur statique incluent des données pour « Hey Cortana » (ou sa traduction) pour toutes les langues prises en charge.

modèle dépendant de l’utilisateur dynamique - IStream fournit un modèle de stockage d’accès aléatoire. Le système d’exploitation passe un pointeur d’interface IStream à plusieurs des méthodes de l’interface IKeywordDetectorOemAdapter. Le système d’exploitation sauvegarde l’implémentation IStream avec un stockage approprié pour un maximum de 1 Mo de données.

Le contenu et la structure des données au sein de ce stockage sont définis par l’OEM. L’objectif prévu est le stockage persistant des données de modèle dépendant de l’utilisateur calculées ou récupérées par la DLL OEM.

Le système d'exploitation peut appeler les méthodes d'interface avec un IStream vide, en particulier si l'utilisateur n'a jamais configuré de mot-clé. Le système d’exploitation crée un stockage IStream distinct pour chaque utilisateur. En d’autres termes, un certain IStream stocke les données de modèle pour un seul utilisateur.

Le développeur DE DLL OEM décide comment gérer les données indépendantes de l’utilisateur et dépendantes de l’utilisateur. Toutefois, il ne doit jamais stocker les données utilisateur n’importe où en dehors de IStream. Une conception de DLL OEM possible basculerait en interne entre l’accès à IStream et les données indépendantes de l’utilisateur statique en fonction des paramètres de la méthode actuelle. Une autre conception pourrait vérifier l'IStream au début de chaque appel de méthode et ajouter les données statiques indépendantes de l'utilisateur à l'IStream si elles ne sont pas déjà présentes, permettant ainsi au reste de la méthode d'accéder uniquement à l'IStream pour toutes les données du modèle.

Formation et traitement audio opérationnel

Comme décrit précédemment, le flux de l’interface utilisateur de formation se traduit par des phrases riches en phonétique disponibles dans le flux audio. Chaque phrase est transmise individuellement à IKeywordDetectorOemAdapter ::VerifyUserKeyword pour vérifier qu’elle contient le mot clé attendu et a une qualité acceptable. Une fois toutes les phrases collectées et vérifiées par l’interface utilisateur, elles sont passées en un seul appel à IKeywordDetectorOemAdapter ::ComputeAndAddUserModelData.

L’audio est traité de manière unique pour l’apprentissage de l’activation vocale. Le tableau suivant résume les différences entre l’apprentissage de l’activation vocale et l’utilisation régulière de la reconnaissance vocale.

Vue d’ensemble du système de reconnaissance de mot clé

Ce diagramme fournit une vue d’ensemble du système de reconnaissance de mot clé.

Diagrammes de séquences de reconnaissance de mot clé

Dans ces diagrammes, le module d’exécution de reconnaissance vocale s’affiche sous la forme de la plateforme vocale. Comme mentionné précédemment, la plateforme de reconnaissance vocale Windows est utilisée pour alimenter toutes les expériences vocales dans Windows 10, telles que Cortana et la dictée.

Lors du démarrage, les capacités sont rassemblées à l’aide de IKeywordDetectorOemAdapter::GetCapabilities.

Plus tard, lorsque l’utilisateur sélectionne « Learn my voice », le flux d’entraînement est appelé.

Ce diagramme décrit le processus d’armement pour la détection de mots-clés.

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 nouvelle 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 des signaux 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_Constraints sur l’interface de périphérique PnP KSCATEGORY_AUDIO du filtre KS qui comporte des 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_Constraints

La valeur de la propriété DEVPKEY_KsAudio_PacketSize_Constraints contient une structure KSAUDIO_PACKETSIZE_CONSTRAINTS décrivant les contraintes matérielles physiques (autrement dit, 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 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 simples (mais moins précises) à assez complexes ou nouvelles (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 une catégorie de broche KSNODETYPE_AUDIO_KEYWORDDETECTOR, le pilote commence à capturer et à effectuer une mise en mémoire tampon interne des données lorsqu’un mot clé est détecté. Dans un autre scénario, le pilote peut mettre en mémoire tampon les 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.

   1. 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 et la position du paquet par rapport au début du flux.

   2. Le pilote retourne également la valeur du compteur de performances qui correspond au moment d'échantillonnage du premier échantillon du paquet. Cette valeur de compteur de performances peut être relativement ancienne, selon 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).

   3. S’il existe des données mises en mémoire tampon non lues disponibles pour le pilote :

      1. Transfère immédiatement ces données dans l’espace disponible de la mémoire tampon WaveRT (autrement dit, 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,
      2. 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 sur la broche avant le dépassement du buffer, le pilote peut mettre fin à l'activité de mise en buffer 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 écran désactivé, à un état d’alimentation inférieur, à un écran activé, en disant un mot clé spécifique, tel que « Hey Cortana ».

Cette fonctionnalité permet à l’appareil d’être toujours à l’écoute de la voix de l’utilisateur pendant que l’appareil est dans un état d’alimentation faible, notamment lorsque l’écran est désactivé et que l’appareil est inactif. Il le fait à l’aide d’un mode d’écoute, ce qui est une puissance inférieure par rapport à l’utilisation plus élevée de l’alimentation observée lors de l’enregistrement normal du microphone. La reconnaissance vocale à faible puissance permet à un utilisateur de dire une expression clé prédéfinie comme « Hey Cortana », suivie d’une expression vocale chaînée comme « quand est mon prochain rendez-vous » pour appeler la parole de manière mains libres. Cela fonctionne, que l’appareil soit en cours d’utilisation ou inactif avec l’écran désactivé.

La pile audio est chargée de communiquer les données de mise en éveil (ID de l’orateur, déclencheur de mot clé, niveau de confiance) et d’informer les clients intéressés que le mot clé est 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.