Activation vocale

  • Article

Notes

Cette rubrique fait principalement référence à nos expériences grand public, qui sont actuellement fournies dans Windows 10 (version 1909 et antérieure) Pour plus d’informations, consultez Fin de la prise en charge de Cortana dans Windows et Teams.

Cortana, la technologie de assistant personnelle a été démontrée pour la première fois lors de la Conférence des développeurs Microsoft BUILD en 2013. La plateforme vocale Windows est utilisée pour alimenter 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 de l’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 de cette rubrique.

Notes

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

Expérience utilisateur finale de Cortana

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

Rubrique Description
Qu’est ce que Cortana ? Fournit une vue d’ensemble et une direction d’utilisation pour Cortana

Présentation de l’activation vocale « Hey Cortana » et de « Apprendre ma voix »

Activation vocale hey Cortana

La fonctionnalité d’activation vocale « Hey Cortana » (VA) permet aux utilisateurs d’engager rapidement l’expérience Cortana en dehors de leur contexte actif (c’est-à-dire ce qui se trouve actuellement à l’écran) en utilisant leur voix. Les utilisateurs veulent souvent pouvoir accéder instantanément à une expérience sans avoir à interagir physiquement avec un appareil. Pour les utilisateurs de téléphone, cela peut être dû à la conduite dans la voiture et à avoir leur attention et les mains engagées avec le fonctionnement du véhicule. Pour un utilisateur Xbox, cela peut être dû à ne pas vouloir rechercher et connecter une manette. Pour les utilisateurs de PC, cela peut être dû à un accès rapide à une expérience sans avoir à effectuer plusieurs actions de souris, tactiles et/ou clavier, par exemple un ordinateur dans la cuisine.

L’activation vocale fournit une entrée vocale toujours à l’écoute via des expressions clés prédéfinies ou des « expressions d’activation ». Les expressions clés peuvent être prononcées par elles-mêmes (« Hey Cortana ») en tant que commande mise en scène, ou suivies d’une action vocale, par exemple, « Hey Cortana, où est ma prochaine réunion ? », une commande chaînée.

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

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

Une commande chaînée décrit la possibilité d’émettre une commande immédiatement après l’mot clé (par exemple, « Hey Cortana, appelez John ») et de faire démarrer Cortana (si ce 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 mot clé uniquement.

Diagramme montrant la différence entre l’activation chaînée et l’activation mot clé uniquement avec mémoire tampon audio et séquence de temps.

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

La fonctionnalité « Apprendre ma voix »

La fonctionnalité « Apprendre ma voix » permet à l’utilisateur d’entraîner Cortana à reconnaître sa voix unique. Pour ce faire, l’utilisateur sélectionne Découvrir 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 des utilisateurs.

Capture d’écran des paramètres du bureau Cortana pour le matériel mot clé fonctionnalité spotter et wake sur la voix.

Lorsque l’activation vocale est associée à « Apprendre ma voix », 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 remplie 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 mot clé (KWS) qui réagit si l’expression clé est détectée. Si le KWS doit sortir l’appareil d’un état de faible puissance, 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.

Terme Exemple/définition
Commande intermédiaire Exemple : Hey Cortana <pause, attendez l’écouteur> Quelle est la météo ? Cela est parfois appelé « commande à deux coups » ou « mot clé uniquement »
Commande chaînée Exemple : Hey Cortana quelle est la météo ? Il s’agit parfois d’une « commande one-shot »
Activation vocale Scénario consistant à fournir mot clé détection d’une clé d’activation prédéfinie. Par exemple, « Hey Cortana » est le scénario d’activation Microsoft Voice.
WoV Wake-on-Voice : technologie qui permet l’activation vocale d’un écran éteint, d’un état d’alimentation inférieur, à un écran à l’état d’alimentation totale.
WoV de veille moderne Wake-on-Voice à partir d’un état d’écran de veille moderne (S0ix) à un état d’écran à pleine alimentation (S0).
Veille moderne Infrastructure d’inactivité à faible consommation d’énergie Windows - successeur de la veille connectée (CS) dans Windows 10. Le premier état de la veille moderne est lorsque l’écran est éteint. L’état de sommeil le plus profond est quand drips/résilience. Pour plus d’informations, consultez Veille moderne
KWS Spotter de mots clés : algorithme qui fournit la détection de « Hey Cortana »
SW KWS Software mot clé spotter : implémentation de KWS qui s’exécute sur l’hôte (UC). Pour « Hey Cortana », SW KWS est inclus dans Windows.
HW KWS Le matériel déchargé mot clé spotter : implémentation de KWS qui s’exécute déchargée sur le matériel.
Mémoire tampon de rafale Mémoire tampon circulaire utilisée pour stocker les données PCM qui peuvent être « éclatées » en cas de détection KWS, de sorte que tout l’audio qui a déclenché une détection KWS soit inclus.
Adaptateur OEM détecteur de mots clés Shim au niveau du pilote qui permet au HW avec WoV de communiquer avec Windows et la pile Cortana.
Modèle Fichier de données de modèle acoustique utilisé par l’algorithme KWS. Le fichier de données est statique. Les modèles sont localisés, un par paramètres régionaux.

Intégration d’un spotter de mots clés matériels

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

Exigences woV de mot clé déchargées matériellement

  • HW KWS WoV est pris en charge pendant l’état de fonctionnement S0 et l’état 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 (veille moderne) AEC n’est pas nécessaire.
    • L’état de fonctionnement de HW KWS WoV pour S0 n’est pas pris en charge dans Windows version 1709.

  • Pour Windows version 1803

    • L’état de fonctionnement HW KWS WoV pour S0 est pris en charge.
    • Pour activer HW KWS WoV pour l’état de fonctionnement de S0, l’APO doit prendre en charge 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 Exemples de pilotes audio.

Informations système de reconnaissance de mot clé

Prise en charge de la pile audio de l’activation vocale

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

  • Détecteur de mots clés Device Driver Interface (DDI). L’interface de pilote de périphérique du détecteur de mots clés est responsable de la configuration et de l’armation du 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 détecteur de mots clés. Cette DLL implémente une interface COM pour adapter les données opaques spécifiques au pilote pour une utilisation par le système d’exploitation afin de faciliter la détection mot clé.
  • Améliorations du streaming WaveRT. Les améliorations permettent au pilote audio de diffuser en rafale les données audio mises en mémoire tampon à partir de la détection mot clé.

Propriétés du point de terminaison audio

La génération de graphiques de point de terminaison audio se produit normalement. Le graphique est prêt à gérer la capture plus rapide que la capture en temps réel. Les horodatages sur les mémoires tampons capturées restent vrais. Plus précisément, les horodatages reflètent correctement les données qui ont été capturées dans le passé et mises en mémoire tampon, et qui sont maintenant en « rafale ».

Théorie de la diffusion en continu audio de contournement 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 fabrique de broches supplémentaire identifiée comme une broche mot clé spotter (KWS). Cette broche est utilisée pour diffuser de l’audio à partir de l’mot clé spotter.

Les propriétés sont les suivantes :

  • Types de mot clé 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 de modèles mot clé - KSPROPERTY_SOUNDDETECTOR_SUPPORTEDPATTERNS. Cette propriété permet d’obtenir la liste des GUID qui identifient les types de modèles pris en charge.
  • Armée - KSPROPERTY_SOUNDDETECTOR_ARMED. Cette propriété en lecture/écriture est une simple status booléenne indiquant si le détecteur est armé. Le système d’exploitation définit ce paramètre pour engager le détecteur de mot clé. Le système d’exploitation peut effacer ce problème pour le désengager. Le pilote efface automatiquement ce paramètre lorsque mot clé modèles sont définis et également après la détection d’un mot clé. (Le système d’exploitation doit se réarmer.)
  • Résultat de la correspondance : KSPROPERTY_SOUNDDETECTOR_MATCHRESULT. Cette propriété read contient les données de résultat une fois la détection effectuée.

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 mot clé pris en charge pour vérifier qu’il contient des mots clés dans ce format.
  2. Le système d’exploitation s’inscrit au détecteur status’événement de modification.
  3. Le système d’exploitation définit les modèles mot clé.
  4. Le système d’exploitation arme le détecteur.

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

  1. Le conducteur désarme le détecteur.
  2. Le système d’exploitation lit le détecteur mot clé status, analyse les données retournées et détermine le modèle qui a été détecté.
  3. Le système d’exploitation réarme le détecteur.

Fonctionnement 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 les 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 elle peut généralement être de plusieurs centaines de millisecondes à plusieurs secondes.) L’algorithme de détection fonctionne sur le streaming de données via cette mémoire tampon. La conception du pilote et du matériel est telle qu’il n’y a pas d’interaction entre le pilote et le matériel et aucune interruption des processeurs « d’application » jusqu’à ce qu’une mot clé soit détectée. 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 effectue la maintenance de l’interruption, le matériel continue de capturer l’audio dans la mémoire tampon, en veillant à ce qu’aucune donnée ne soit perdue après la perte de l’mot clé, dans les limites de mise en mémoire tampon.

Timestamps de mot clé

Après avoir détecté un mot clé, toutes les solutions d’activation vocale doivent mettre en mémoire tampon tous les mot clé parlés, y compris 250 ms avant le début de la 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/de fin mot clé, le logiciel DSP peut avoir besoin d’horodatage interne des événements en fonction d’une horloge DSP. Une fois qu’une mot clé est détectée, 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 performances Windows. La méthode utilisée pour effectuer cette opération est spécifique à la conception matérielle. Une solution possible consiste pour le pilote à lire le compteur de performances actuel, à interroger l’horodatage DSP actuel, à lire à nouveau le compteur de performances actuel, puis à estimer une corrélation entre le compteur de performances et le temps DSP. Ensuite, étant donné la corrélation, le pilote peut mapper les horodatages mot clé DSP aux horodatages du compteur de performances Windows.

Interface d’adaptateur OEM du détecteur de mots clés

L’OEM fournit une implémentation d’objet COM qui joue le rôle d’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 retourné par le 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 mot clé type de modèle et appelle des méthodes sur l’interface IKeywordDetectorOemAdapter de l’objet.

Configuration requise pour le modèle de thread 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 conserver l’implémentation de l’objet sans état. En d’autres termes, l’implémentation doit exiger qu’aucun état ne soit stocké 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.

KEYWORDID

L’énumération KEYWORDID identifie le texte/fonction d’expression 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 - Composants de plateforme de base

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

KEYWORDSELECTOR

Le struct KEYWORDSELECTOR est un ensemble d’ID qui sélectionnent de manière unique une mot clé et une langue particulières.

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

Gestion des données du modèle

Modèle statique indépendant de l’utilisateur : la DLL OEM inclut généralement des données de modèle statique indépendantes de l’utilisateur, soit intégrées à la DLL, soit dans un fichier de données distinct inclus avec 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 statique indépendantes de l’utilisateur incluent des données pour « Hey Cortana » (ou sa traduction) pour toutes les langues prises en charge.

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

Le contenu et la structure des données dans ce stockage sont définis par l’OEM. L’objectif prévu est le stockage persistant des données de modèle dépendantes 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 formé un mot clé. Le système d’exploitation crée un stockage IStream distinct pour chaque utilisateur. En d’autres termes, un IStream donné 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 de données utilisateur en dehors de l’IStream. Une conception de DLL OEM possible basculerait en interne entre l’accès à L’IStream et les données statiques indépendantes de l’utilisateur en fonction des paramètres de la méthode actuelle. Une autre conception peut case activée 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, ce qui permet au reste de la méthode d’accéder uniquement à l’IStream pour toutes les données de modèle.

Traitement audio d’entraînement et d’opération

Comme décrit précédemment, le flux d’interface utilisateur d’entraînement entraîne la disponibilité de phrases complètes phonétiquement riches dans le flux audio. Chaque phrase est transmise individuellement à IKeywordDetectorOemAdapter ::VerifyUserKeyword pour vérifier qu’elle contient le mot clé attendu et qu’elle a une qualité acceptable. Une fois toutes les phrases collectées et vérifiées par l’interface utilisateur, elles sont toutes passées en un seul appel à IKeywordDetectorOemAdapter ::ComputeAndAddUserModelData.

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

|

Formation vocale Reconnaissance vocale
Mode Brut Raw ou Speech
Épingler Normal KWS
Audio Format Float 32 bits (Type = Audio, Sous-type = IEEE_FLOAT, Taux d’échantillonnage = 16 kHz, bits = 32) Géré par la pile audio du système d’exploitation
Micro Micro 0 Tous les micros en tableau, ou mono

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

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

Diagramme du système de reconnaissance mot clé, y compris Cortana, le runtime vocal et les composants du gestionnaire d’activation vocale.

Diagrammes de séquence de reconnaissance de mots clés

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

Au démarrage, les fonctionnalités sont collectées à l’aide de IKeywordDetectorOemAdapter ::GetCapabilities.

Diagramme de séquence de la reconnaissance mot clé au démarrage, montrant l’expérience utilisateur d’entraînement, la plateforme vocale et le détecteur de mot clé OEM.

Plus tard, lorsque l’utilisateur sélectionne « Apprendre ma voix », le flux d’entraînement est appelé.

Diagramme de séquence de la reconnaissance de mot clé pendant le processus « Apprendre ma voix », montrant l’expérience utilisateur d’entraînement, la plateforme vocale et le détecteur de mot clé OEM.

Ce diagramme décrit le processus d’armement pour mot clé détection.

Diagramme de séquence de la reconnaissance mot clé pendant l’armement pour la détection de mot clé, montrant la plateforme vocale, le détecteur oem mot clé et le détecteur de lecteurs audio.

Améliorations de WAVERT

Les interfaces miniport sont définies pour être implémentées par les pilotes de 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 de périphérique PnP est définie, ce qui permet au pilote de fournir une expression statique de ses contraintes de taille de mémoire tampon au système d’exploitation.

Tailles de mémoire 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 aux modules de traitement du signal au sein du matériel ou du 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 mémoire tampon en définissant la propriété d’appareil DEVPKEY_KsAudio_PacketSize_Constraints sur l’interface d’appareil PnP KSCATEGORY_AUDIO du filtre KS qui a la ou les broches de streaming KS. Cette propriété doit rester valide et stable tant que l’interface de filtre KS est activée. Le système d’exploitation peut lire cette valeur à tout moment sans avoir à ouvrir de handle sur 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 (c’est-à-dire en raison des mécanismes de transfert des données de la mémoire tampon WaveRT vers le matériel audio). La structure comprend un tableau de 0 ou plus KSAUDIO_PACKETSIZE_PROCESSINGMODE_CONSTRAINT structures décrivant des contraintes spécifiques à tous les modes de traitement du signal. Le pilote définit cette propriété avant d’appeler PcRegisterSubdevice ou d’activer 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 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 implémente éventuellement cette interface pour être informé de la progression de l’écriture à partir du système d’exploitation et pour retourner une position précise du flux. Pour plus d’informations, consultez IMiniportWaveRTOutputStream ::SetWritePacket, IMiniportWaveRTOutputStream ::GetOutputStreamPresentationPosition et IMiniportWaveRTOutputStream ::GetPacketCount.

Horodatages du compteur de performances

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

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

  • Dans le DSP, suivez les exemples d’horodatages à l’aide d’une horloge murale DSP interne.
  • 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 simple (mais moins précis) à assez complexe ou nouveau (mais plus précis).
  • Tenez compte des retards constants dus aux algorithmes de traitement du signal ou aux transports de pipeline ou matériels, sauf si ces retards sont autrement pris en compte.

Opération de lecture en rafale

Cette section décrit l’interaction entre le système d’exploitation et le 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 à tamponner les données en interne lorsqu’une mot clé est détectée. 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 assez rapidement en appelant IMiniportWaveRTInputStream ::GetReadPacket.

Pour les données de rafale capturées avant la transition vers KSSTATE_RUN, le pilote doit conserver des informations d’échantillonnage d’horodatage précises, ainsi que les données de capture mises en mémoire tampon. Les horodatages identifient l’instant 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 à l’instant d’échantillonnage du premier échantillon dans le paquet. Notez que cette valeur de compteur de performances peut être relativement ancienne, en fonction de la quantité de données de capture qui ont été mises en mémoire tampon dans le matériel ou le pilote (en dehors de la mémoire tampon WaveRT).

    c. S’il existe plus de données mises en mémoire tampon non lues disponibles, le pilote : 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 à partir 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 et définit ultérieurement 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 le prochain événement de notification de mémoire tampon. L’attente peut se terminer immédiatement si le pilote a défini 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), il définit l’événement après avoir transféré davantage de données capturées dans la mémoire tampon WaveRT et les met à la disposition du système d’exploitation pour la lecture

  6. Accédez à (2). Pour KSNODETYPE_AUDIO_KEYWORDDETECTOR mot clé broches de détecteur, les pilotes doivent allouer suffisamment de mémoire tampon interne pour au moins 5 000 ms de données audio. Si le système d’exploitation ne parvient pas à créer un flux 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.

Wake on Voice

Wake On Voice (WoV) permet à l’utilisateur d’activer et d’interroger un moteur de reconnaissance vocale à partir d’un écran éteint, d’un état d’alimentation inférieur, à un écran allumé, à un état d’alimentation totale en disant un certain mot clé, comme « 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 de faible consommation, y compris lorsque l’écran est éteint et que l’appareil est inactif. Pour ce faire, il utilise un mode d’écoute, qui est plus faible que la consommation d’énergie beaucoup plus élevée observée lors de l’enregistrement normal du microphone. La reconnaissance vocale à faible puissance permet à un utilisateur de dire simplement une phrase 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 lorsque l’écran est désactivé.

La pile audio est chargée de communiquer les données d’éveil (ID de l’orateur, déclencheur mot clé, niveau de confiance) et d’informer les clients intéressés que le mot clé a été détecté.

Validation sur les systèmes de secours modernes

Le woV à partir d’un état d’inactivité du système peut être validé sur les systèmes de secours modernes à l’aide du test de base de veille moderne sur la voix sur la source d’alimentation CA et du test de base veille moderne sur la source d’alimentation DC dans le HLK. Ces tests case activée que le système dispose d’un spotter de mot clé matériel (HW-KWS), qu’il peut entrer dans l’état de plateforme d’inactivité du runtime le plus profond (DRIPS) et qu’il peut sortir de la veille moderne sur commande vocale avec une latence de reprise du système inférieure ou égale à une seconde.