Voice-Aktivierung

  • Artikel

Hinweis

Dieses Thema bezieht sich hauptsächlich auf unsere Benutzeroberflächen, die derzeit in Windows 10 (Version 1909 und früher) bereitgestellt werden. Weitere Informationen finden Sie unter Ende des Supports für Cortana in Windows und Teams.

Cortana, die persönliche Assistent Technologie, wurde erstmals auf der Microsoft BUILD Developer Conference 2013 vorgestellt. Die Windows-Sprachplattform wird verwendet, um alle Sprachfunktionen in Windows 10 wie Cortana und Diktieren zu unterstützen. Die Sprachaktivierung ist ein Feature, mit dem Benutzer eine Spracherkennungs-Engine aus verschiedenen Geräteleistungszuständen aufrufen können, indem sie einen bestimmten Ausdruck sagen: "Hey Cortana". Informationen zum Erstellen von Hardware, die die Sprachaktivierungstechnologie unterstützt, finden Sie in den Informationen in diesem Thema.

Hinweis

Die Implementierung der Sprachaktivierung ist ein wichtiges Projekt und eine Aufgabe, die von SoC-Anbietern abgeschlossen wird. OEMs können sich an ihren SoC-Anbieter wenden, um Informationen zur Implementierung der Sprachaktivierung durch ihr SoC zu erhalten.

Cortana-Endbenutzererfahrung

Informationen zur Sprachinteraktion in Windows finden Sie in diesen Themen.

Thema BESCHREIBUNG
Was ist Cortana? Bietet eine Übersicht und Verwendungsrichtung für Cortana.

Einführung in die Sprachaktivierung "Hey Cortana" und "Meine Stimme lernen"

Hey Cortana" Sprachaktivierung

Das Feature "Hey Cortana" voice activation (VA) ermöglicht Es Benutzern, die Cortana-Erfahrung schnell außerhalb ihres aktiven Kontexts (d. h. was sich derzeit auf dem Bildschirm befindet) mithilfe ihrer Stimme zu interagieren. Benutzer möchten häufig in der Lage sein, sofort auf eine Erfahrung zuzugreifen, ohne ein Gerät physisch interagieren zu müssen. Für Telefonbenutzer kann dies darauf zurückzuführen sein, dass sie im Auto fahren und ihre Aufmerksamkeit und Ihre Hände beim Bedienen des Fahrzeugs beschäftigt sind. Für einen Xbox-Benutzer kann dies darauf zurückzuführen sein, dass er einen Controller nicht finden und anschließen möchte. Für PC-Benutzer kann dies auf einen schnellen Zugriff auf ein Erlebnis zurückzuführen sein, ohne mehrere Maus-, Touch- und/oder Tastaturaktionen durchführen zu müssen, z. B. ein Computer in der Küche.

Die Sprachaktivierung ermöglicht immer lauschende Spracheingaben über vordefinierte Schlüsselbegriffe oder "Aktivierungsbegriffe". Schlüsselbegriffe können von sich selbst ("Hey Cortana") als inszenierter Befehl oder gefolgt von einer Sprachaktion, z. B. "Hey Cortana, wo ist meine nächste Besprechung?", ein verketteter Befehl, ausgesprochen werden.

Der Begriff Schlüsselworterkennung beschreibt die Erkennung der Schlüsselwort (keyword) durch Hardware oder Software.

Die Schlüsselwortaktivierung tritt nur auf, wenn nur die Cortana-Schlüsselwort (keyword) gesagt wird. Cortana startet und gibt den EarCon-Sound wieder, um anzugeben, dass es in den Lauschmodus gewechselt ist.

Ein verketteter Befehl beschreibt die Fähigkeit, einen Befehl direkt nach dem Schlüsselwort (keyword) (z. B. "Hey Cortana, call John") auszugeben und Cortana starten (sofern nicht bereits gestartet) und dem Befehl folgen (starten eines Telefonanrufs mit John).

Dieses Diagramm veranschaulicht die verkettete und nur Schlüsselwort (keyword) Aktivierung.

Diagramm, das den Unterschied zwischen verketteter und Schlüsselwort (keyword) ausschließlicher Aktivierung mit Audiopuffer und Zeitsequenz zeigt.

Microsoft bietet einen Standardmäßig-Schlüsselwort (keyword)-Spotter (Software Schlüsselwort (keyword) Spotter), der verwendet wird, um die Qualität der Hardware Schlüsselwort (keyword) Erkennungen sicherzustellen und die Hey Cortana-Erfahrung in Fällen bereitzustellen, in denen die Erkennung von Hardware Schlüsselwort (keyword) fehlt. oder nicht verfügbar.

Das Feature "Meine Stimme lernen"

Mit der Funktion "Meine Stimme lernen" kann der Benutzer Cortana so trainieren, dass es seine eindeutige Stimme erkennt. Dies wird erreicht, indem der Benutzer auf dem Bildschirm mit den Cortana-Einstellungen die Option Learn how I say "Hey Cortana" (Hey Cortana) auswählt. Der Benutzer wiederholt dann sechs sorgfältig ausgewählte Ausdrücke, die eine ausreichende Vielfalt an phonetischen Mustern bieten, um die eindeutigen Attribute der Stimme des Benutzers zu identifizieren.

Screenshot der Cortana-Desktopeinstellungen für Hardware Schlüsselwort (keyword) Spotter und Wake on Voice-Funktion.

Wenn die Sprachaktivierung mit "Learn my voice" gekoppelt wird, arbeiten die beiden Algorithmen zusammen, um Fehlaktivierungen zu reduzieren. Dies ist besonders wertvoll für das Besprechungsraumszenario, in dem eine Person "Hey Cortana" in einem Raum voller Geräte sagt. Dieses Feature ist nur für Windows 10 Version 1903 und früher verfügbar.

Die Sprachaktivierung wird durch einen Schlüsselwort (keyword) Spotter (KWS) unterstützt, der reagiert, wenn der Schlüsselbegriff erkannt wird. Wenn der KWS das Gerät aus einem zustand mit geringer Leistung reaktivieren soll, wird die Lösung als Wake on Voice (WoV) bezeichnet. Weitere Informationen finden Sie unter Wake on Voice.

Glossarbegriffe

Dieses Glossar fasst Begriffe im Zusammenhang mit der Sprachaktivierung zusammen.

Begriff Beispiel/Definition
Mehrstufiger Befehl Beispiel: Hey Cortana <pause, wait for earcon> What's the weather? Dies wird manchmal als "Two-Shot-Befehl" oder "Nur Schlüsselwort" bezeichnet.
Verketteter Befehl Beispiel: Hey Cortana wie ist das Wetter? Dies wird manchmal als "One-Shot-Befehl" bezeichnet.
Voice-Aktivierung Das Szenario der Bereitstellung Schlüsselwort (keyword) Erkennung einer vordefinierten Aktivierungsschlüsselphrase. Beispielsweise ist "Hey Cortana" das Microsoft-Sprachaktivierungsszenario.
WoV Wake-on-Voice - Technologie, die die Sprachaktivierung von einem ausgeschalteten Bildschirm, einem niedrigeren Energiezustand bis zu einem Bildschirm mit vollem Energiezustand ermöglicht.
WoV aus modernem Standbymodus Wake-on-Voice von einem S0ix-Bildschirm (Modern Standby) zu einem Bildschirm im Vollstromzustand (S0).
Moderner Standby-Modus Windows Low Power Idle Infrastructure – Nachfolger von Connected Standby (CS) in Windows 10. Der erste Zustand des modernen Standbymodus ist, wenn der Bildschirm ausgeschaltet ist. Der tiefste Ruhezustand ist in DRIPS/Resilienz. Weitere Informationen finden Sie unter Moderner Standbymodus.
KWS Keyword Spotter – der Algorithmus, der die Erkennung von "Hey Cortana" bereitstellt
SW KWS Software Schlüsselwort (keyword) Spotter – eine Implementierung von KWS, die auf dem Host (CPU) ausgeführt wird. Für "Hey Cortana" ist SW KWS als Teil von Windows enthalten.
HW KWS Hardware-offloaded Schlüsselwort (keyword) Spotter – eine Implementierung von KWS, die auf Hardware ausgelagert ausgeführt wird.
Burstpuffer Ein kreisförmiger Puffer zum Speichern von PCM-Daten, die im Falle einer KWS-Erkennung "bursted" werden können, sodass alle Audiodaten enthalten sind, die eine KWS-Erkennung ausgelöst haben.
OEM-Adapter für die Schlüsselworterkennung Ein Shim auf Treiberebene, der es dem WoV-fähigen HW ermöglicht, mit Windows und dem Cortana-Stapel zu kommunizieren.
Modell Die vom KWS-Algorithmus verwendete Akustikmodelldatendatei. Die Datendatei ist statisch. Modelle werden lokalisiert, 1 pro Gebietsschema.

Integrieren eines Hardware-Schlüsselwort-Spotters

Um eine Hardware Schlüsselwort (keyword) Spotter (HW KWS) zu implementieren, müssen SoC-Anbieter die folgenden Aufgaben ausführen.

Hardwareausgeladene Schlüsselwort (keyword)-Spotter (HW KWS) WoV-Anforderungen

  • HW KWS WoV wird während des S0-Betriebszustands und des S0-Ruhezustands unterstützt, der auch als Modern Standby bezeichnet wird.
  • HW KWS WoV wird von S3 nicht unterstützt.

AEC-Anforderungen für HW KWS

  • Für Windows Version 1709

    • Zur Unterstützung von HW KWS WoV für den Ruhezustand S0 (Modern Standby) ist AEC nicht erforderlich.
    • HW KWS WoV for S0 working state wird in Windows Version 1709 nicht unterstützt.

  • Für Windows Version 1803

    • HW KWS WoV for S0 working state wird unterstützt.
    • Um HW KWS WoV für den Arbeitszustand S0 zu aktivieren, muss der APO AEC unterstützen.

Übersicht über Beispielcode

Es gibt Beispielcode für einen Audiotreiber, der die Sprachaktivierung auf GitHub als Teil des Beispiels für den virtuellen SYSVAD-Audioadapter implementiert. Es wird empfohlen, diesen Code als Ausgangspunkt zu verwenden. Der Code ist an diesem Speicherort verfügbar.

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

Weitere Informationen zum SYSVAD-Beispiel-Audiotreiber finden Sie unter Beispielaudiotreiber.

Schlüsselworterkennungssysteminformationen

Unterstützung für Audiostapel für die Sprachaktivierung

Die externen Schnittstellen des Audiostapels zum Aktivieren der Sprachaktivierung dienen als Kommunikationspipeline für die Sprachplattform und die Audiotreiber. Die externen Schnittstellen sind in drei Teile unterteilt.

  • Schlüsselworterkennung Device Driver Interface (DDI). Die Schnittstelle des Schlüsselworterkennungsgerätetreibers ist für das Konfigurieren und Ausrüsten des HW-Schlüsselwort-Spotters (KWS) verantwortlich. Es wird auch vom Treiber verwendet, um das System über ein Erkennungsereignis zu benachrichtigen.
  • Schlüsselworterkennungs-OEM-Adapter-DLL. Diese DLL implementiert eine COM-Schnittstelle, um die treiberspezifischen undurchsichtigen Daten für die Verwendung durch das Betriebssystem anzupassen, um Schlüsselwort (keyword) Erkennung zu unterstützen.
  • WaveRT-Streamingerweiterungen. Die Verbesserungen ermöglichen es dem Audiotreiber, die gepufferten Audiodaten aus der Schlüsselwort (keyword) Erkennung zu streamen.

Audioendpunkteigenschaften

Das Erstellen eines Audioendpunktdiagramms erfolgt normal. Das Diagramm ist so vorbereitet, dass es schneller als die Echtzeiterfassung verarbeitet. Zeitstempel auf erfassten Puffern bleiben wahr. Insbesondere spiegeln die Zeitstempel daten, die in der Vergangenheit erfasst und gepuffert wurden, korrekt wider und sind jetzt "bursting".

Theorie der Bluetooth-Umgehung von Audiostreaming

Der Treiber macht wie gewohnt einen KS-Filter für sein Erfassungsgerät verfügbar. Dieser Filter unterstützt mehrere KS-Eigenschaften und ein KS-Ereignis zum Konfigurieren, Aktivieren und Signalisieren eines Erkennungsereignisses. Der Filter enthält auch eine zusätzliche Pin factory, die als Schlüsselwort (keyword)-Spotter(KWS)-Pin identifiziert ist. Dieser Pin wird verwendet, um Audiodaten aus dem Schlüsselwort (keyword)-Spotter zu streamen.

Dabei handelt es sich um die folgenden Eigenschaften:

  • Unterstützte Schlüsselwort (keyword) Typen: KSPROPERTY_SOUNDDETECTOR_PATTERNS. Diese Eigenschaft wird vom Betriebssystem festgelegt, um die zu erkennenden Schlüsselwörter zu konfigurieren.
  • Liste mit Schlüsselwort (keyword) Muster-GUIDs – KSPROPERTY_SOUNDDETECTOR_SUPPORTEDPATTERNS. Diese Eigenschaft wird verwendet, um eine Liste von GUIDs abzurufen, die die Typen der unterstützten Muster identifizieren.
  • Bewaffnet - KSPROPERTY_SOUNDDETECTOR_ARMED. Diese Lese-/Schreibeigenschaft ist ein einfach boolescher status, der angibt, ob der Detektor bewaffnet ist. Das Betriebssystem legt dies so fest, dass der Schlüsselwort (keyword)-Detektor verwendet wird. Das Betriebssystem kann dies löschen, um sich zu trennen. Der Treiber löscht dies automatisch, wenn Schlüsselwort (keyword) Muster festgelegt werden und auch nachdem ein Schlüsselwort (keyword) erkannt wurde. (Das Betriebssystem muss umgestalten.)
  • Übereinstimmungsergebnis: KSPROPERTY_SOUNDDETECTOR_MATCHRESULT. Diese Read-Eigenschaft enthält die Ergebnisdaten nach der Erkennung.

Das Ereignis, das ausgelöst wird, wenn ein Schlüsselwort (keyword) erkannt wird, ist ein KSEVENT_SOUNDDETECTOR_MATCHDETECTED-Ereignis.

Ablauf des Vorgangs

Systemstart

  1. Das Betriebssystem liest die unterstützten Schlüsselwort (keyword)-Typen, um sicherzustellen, dass es Schlüsselwörter in diesem Format enthält.
  2. Das Betriebssystem registriert sich für den Detektor status Änderungsereignis.
  3. Das Betriebssystem legt die Schlüsselwort (keyword)-Muster fest.
  4. Das Betriebssystem unterstützt den Detektor.

Beim Empfangen des KS-Ereignisses

  1. Der Treiber entwaffnet den Detektor.
  2. Das Betriebssystem liest die Schlüsselwort (keyword)-Detektor-status, analysiert die zurückgegebenen Daten und bestimmt, welches Muster erkannt wurde.
  3. Das Betriebssystem erstellt den Detektor neu.

Interner Treiber- und Hardwarebetrieb

Während der Detektor bewaffnet ist, kann die Hardware kontinuierlich Audiodaten in einem kleinen FIFO-Puffer erfassen und puffern. (Die Größe dieses FIFO-Puffers wird durch Anforderungen außerhalb dieses Dokuments bestimmt, kann jedoch in der Regel Hunderte von Millisekunden bis mehrere Sekunden betragen.) Der Erkennungsalgorithmus arbeitet mit dem Datenstreaming über diesen Puffer. Das Design des Treibers und der Hardware ist so, dass es während der Bewaffnung keine Interaktion zwischen Treiber und Hardware und keine Unterbrechungen für die "Anwendungs"-Prozessoren gibt, bis ein Schlüsselwort (keyword) erkannt wird. Dadurch kann das System einen niedrigeren Leistungszustand erreichen, wenn keine andere Aktivität vorhanden ist.

Wenn die Hardware einen Schlüsselwort (keyword) erkennt, generiert sie einen Interrupt. Während sie darauf wartet, dass der Treiber den Interrupt bedient, erfasst die Hardware weiterhin Audiodaten im Puffer, um sicherzustellen, dass keine Daten nach dem Schlüsselwort (keyword) verloren gehen, innerhalb der Puffergrenzwerte.

Schlüsselwortzeitstempel

Nach dem Erkennen eines Schlüsselwort (keyword) müssen alle Sprachaktivierungslösungen alle gesprochenen Schlüsselwort (keyword) puffern, einschließlich 250 ms vor Beginn der Schlüsselwort (keyword). Der Audiotreiber muss Zeitstempel bereitstellen, die den Anfang und das Ende des Schlüsselbegriffs im Stream identifizieren.

Um die Schlüsselwort (keyword) Start-/Endzeitstempel zu unterstützen, muss die DSP-Software möglicherweise interne Zeitstempelereignisse basierend auf einer DSP-Uhr ausführen. Sobald ein Schlüsselwort (keyword) erkannt wurde, interagiert die DSP-Software mit dem Treiber, um ein KS-Ereignis vorzubereiten. Der Treiber und die DSP-Software müssen die DSP-Zeitstempel einem Windows-Leistungsindikatorwert zuordnen. Die Methode hierfür ist spezifisch für den Hardwareentwurf. Eine mögliche Lösung besteht darin, dass der Treiber den aktuellen Leistungsindikator liest, den aktuellen DSP-Zeitstempel abfragt, den aktuellen Leistungsindikator erneut liest und dann eine Korrelation zwischen Leistungsindikator und DSP-Zeit schätzt. Aufgrund der Korrelation kann der Treiber dann die Schlüsselwort (keyword) DSP-Zeitstempel den Zeitstempeln des Windows-Leistungsindikators zuordnen.

Oem-Adapterschnittstelle für Schlüsselworterkennung

Der OEM stellt eine COM-Objektimplementierung bereit, die als Vermittler zwischen dem Betriebssystem und dem Treiber fungiert und dabei hilft, die undurchsichtigen Daten zu berechnen oder zu analysieren, die über KSPROPERTY_SOUNDDETECTOR_PATTERNS und KSPROPERTY_SOUNDDETECTOR_MATCHRESULT in den Audiotreiber geschrieben und gelesen werden.

Die CLSID des COM-Objekts ist eine Detektormustertyp-GUID, die vom KSPROPERTY_SOUNDDETECTOR_SUPPORTEDPATTERNS zurückgegeben wird. Das Betriebssystem ruft CoCreateInstance auf und übergibt die Mustertyp-GUID, um das entsprechende COM-Objekt zu instanziieren, das mit Schlüsselwort (keyword) Mustertyp kompatibel ist, und ruft Methoden für die IKeywordDetectorOemAdapter-Schnittstelle des Objekts auf.

COM-Threadingmodellanforderungen

Die Implementierung des OEM kann eines der COM-Threadingmodelle auswählen.

IKeywordDetectorOemAdapter

Der Schnittstellenentwurf versucht, die Objektimplementierung zustandslos zu halten. Anders ausgedrückt: Für die Implementierung sollte zwischen Methodenaufrufen kein Zustand gespeichert werden. In der Tat benötigen interne C++-Klassen wahrscheinlich keine Membervariablen, die über die zum Implementieren eines COM-Objekts im Allgemeinen erforderlichen Variablen hinausgehen.

Methoden

Implementieren Sie die folgenden Methoden.

KEYWORDID

Die KEYWORDID-Enumeration identifiziert den Text/die Funktion eines Schlüsselwort (keyword) und wird auch in den Windows-Biometrischen Dienstadaptern verwendet. Weitere Informationen finden Sie unter Biometric Framework Overview – Core Platform Components

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

KEYWORDSELECTOR

Die KEYWORDSELECTOR-Struktur ist eine Gruppe von IDs, die eine bestimmte Schlüsselwort (keyword) und Sprache eindeutig auswählen.

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

Behandeln von Modelldaten

Statisches benutzerunabhängiges Modell : Die OEM-DLL enthält in der Regel einige statische benutzerunabhängige Modelldaten, die entweder in die DLL oder in einer separaten Datendatei integriert sind, die in der DLL enthalten ist. Der Satz der unterstützten Schlüsselwort (keyword) IDs, die von der GetCapabilities-Routine zurückgegeben werden, hängt von diesen Daten ab. Wenn die Liste der unterstützten Schlüsselwort (keyword) IDs, die von GetCapabilities zurückgegeben werden, beispielsweise KwHeyCortana enthält, würden die statischen benutzerunabhängigen Modelldaten Daten für "Hey Cortana" (oder deren Übersetzung) für alle unterstützten Sprachen enthalten.

Dynamisches benutzerabhängiges Modell : IStream stellt ein Speichermodell für zufälligen Zugriff bereit. Das Betriebssystem übergibt einen IStream-Schnittstellenzeiger an viele der Methoden auf der IKeywordDetectorOemAdapter-Schnittstelle. Das Betriebssystem sichert die IStream-Implementierung mit entsprechendem Speicher für bis zu 1 MB Daten.

Der Inhalt und die Struktur der Daten in diesem Speicher werden vom OEM definiert. Der beabsichtigte Zweck ist die dauerhafte Speicherung von benutzerabhängigen Modelldaten, die von der OEM-DLL berechnet oder abgerufen werden.

Das Betriebssystem kann die Schnittstellenmethoden mit einem leeren IStream aufrufen, insbesondere wenn der Benutzer noch nie eine Schlüsselwort (keyword) trainiert hat. Das Betriebssystem erstellt einen separaten IStream-Speicher für jeden Benutzer. Mit anderen Worten, ein bestimmter IStream speichert Modelldaten für nur einen Benutzer.

Der OEM-DLL-Entwickler entscheidet, wie die benutzerunabhängigen und benutzerabhängigen Daten verwaltet werden sollen. Es darf jedoch niemals Benutzerdaten außerhalb von IStream speichern. Ein möglicher OEM-DLL-Entwurf würde intern zwischen dem Zugriff auf den IStream und den statischen benutzerunabhängigen Daten wechseln, abhängig von den Parametern der aktuellen Methode. Ein alternativer Entwurf kann den IStream zu Beginn jedes Methodenaufrufs überprüfen und die statischen benutzerunabhängigen Daten dem IStream hinzufügen, falls nicht bereits vorhanden, sodass der Rest der Methode nur auf den IStream für alle Modelldaten zugreifen kann.

Audioverarbeitung für Training und Betrieb

Wie bereits beschrieben, führt der Trainings-UI-Flow dazu, dass vollständige phonetisch reiche Sätze im Audiostream verfügbar sind. Jeder Satz wird einzeln an IKeywordDetectorOemAdapter::VerifyUserKeyword übergeben, um zu überprüfen, ob er die erwartete Schlüsselwort (keyword) enthält und eine akzeptable Qualität aufweist. Nachdem alle Sätze von der Benutzeroberfläche erfasst und überprüft wurden, werden sie alle in einem Aufruf an IKeywordDetectorOemAdapter::ComputeAndAddUserModelData übergeben.

Audio wird auf einzigartige Weise für das Sprachaktivierungstraining verarbeitet. In der folgenden Tabelle sind die Unterschiede zwischen dem Sprachaktivierungstraining und der regulären Spracherkennungsverwendung zusammengefasst.

|

Sprachtraining Spracherkennung
Mode Raw Rohformat oder Spracherkennung
Pin Normal KWS
Audioformat 32-Bit Float (Type = Audio, Subtype = IEEE_FLOAT, SamplingRate = 16 kHz, Bits = 32) Verwaltet vom Betriebssystem-Audiostapel
Mic Mikrofon 0 Alle Mikrofone im Array oder Mono

Übersicht über das Schlüsselworterkennungssystem

Dieses Diagramm bietet einen Überblick über das Schlüsselwort (keyword) Erkennungssystem.

Diagramm mit Schlüsselwort (keyword) Erkennungssystem, einschließlich Cortana, Sprachlaufzeit und Sprachaktivierungs-Manager-Komponenten.

Schlüsselworterkennungssequenzdiagramme

In diesen Diagrammen wird das Sprachlaufzeitmodul als "Sprachplattform" dargestellt. Wie bereits erwähnt, wird die Windows-Sprachplattform verwendet, um alle Spracherfahrungen in Windows 10 wie Cortana und Diktat zu unterstützen.

Beim Start werden Funktionen mithilfe von IKeywordDetectorOemAdapter::GetCapabilities erfasst.

Sequenzdiagramm der Schlüsselwort (keyword) Erkennung während des Startvorgangs mit Trainings-UX, Sprachplattform und OEM-Schlüsselwort (keyword)-Detektor

Wenn der Benutzer später "Meine Stimme lernen" auswählt, wird der Trainingsablauf aufgerufen.

Sequenzdiagramm der Schlüsselwort (keyword) Erkennung während des Prozesses

In diesem Diagramm wird der Prozess der Bearmung für Schlüsselwort (keyword) Erkennung beschrieben.

Sequenzdiagramm der Schlüsselwort (keyword) Erkennung während der Bearmung für Schlüsselwort (keyword) Erkennung mit Sprachplattform, OEM-Schlüsselwort (keyword)-Detektor und Audioantriebsdetektor

WAVERT-Verbesserungen

Miniportschnittstellen werden für die Implementierung durch WaveRT-Miniporttreiber definiert. Diese Schnittstellen bieten Methoden, um entweder den Audiotreiber zu vereinfachen, die Leistung und Zuverlässigkeit der Audiopipeline des Betriebssystems zu verbessern oder neue Szenarien zu unterstützen. Eine neue PnP-Geräteschnittstelleneigenschaft wird definiert, die es dem Treiber ermöglicht, statische Ausdrücke seiner Puffergrößeneinschränkungen für das Betriebssystem bereitzustellen.

Puffergrößen

Ein Treiber arbeitet unter verschiedenen Einschränkungen, wenn Audiodaten zwischen dem Betriebssystem, dem Treiber und der Hardware verschoben werden. Diese Einschränkungen können auf den physischen Hardwaretransport zurückzuführen sein, der Daten zwischen Arbeitsspeicher und Hardware verschiebt, und/oder aufgrund der Signalverarbeitungsmodule innerhalb der Hardware oder des zugehörigen DSP.

HW-KWS-Lösungen müssen Audioerfassungsgrößen von mindestens 100 ms und bis zu 200 ms unterstützen.

Der Treiber drückt die Puffergrößeneinschränkungen aus, indem er die DEVPKEY_KsAudio_PacketSize_Constraints-Geräteeigenschaft auf der KSCATEGORY_AUDIO PnP-Geräteschnittstelle des KS-Filters mit den KS-Streaming-Pins festlegt. Diese Eigenschaft sollte gültig und stabil bleiben, während die KS-Filterschnittstelle aktiviert ist. Das Betriebssystem kann diesen Wert jederzeit lesen, ohne einen Handle für den Treiber öffnen und den Treiber aufrufen zu müssen.

DEVPKEY_KsAudio_PacketSize_Constraints

Der DEVPKEY_KsAudio_PacketSize_Constraints-Eigenschaftswert enthält eine KSAUDIO_PACKETSIZE_CONSTRAINTS-Struktur , die die physischen Hardwareeinschränkungen (d. h. aufgrund der Mechanik der Übertragung von Daten aus dem WaveRT-Puffer auf die Audiohardware) beschreibt. Die Struktur enthält ein Array von mindestens 0 KSAUDIO_PACKETSIZE_PROCESSINGMODE_CONSTRAINT Strukturen, die Einschränkungen beschreiben, die für alle Signalverarbeitungsmodi spezifisch sind. Der Treiber legt diese Eigenschaft fest, bevor PcRegisterSubdevice aufgerufen oder anderweitig seine KS-Filterschnittstelle für die Streamingpins aktiviert wird.

IMiniportWaveRTInputStream

Ein Treiber implementiert diese Schnittstelle für eine bessere Koordination des Audiodatenflusses vom Treiber zum Betriebssystem. Wenn diese Schnittstelle für einen Aufzeichnungsstream verfügbar ist, verwendet das Betriebssystem Methoden für diese Schnittstelle, um auf Daten im WaveRT-Puffer zuzugreifen. Weitere Informationen finden Sie unter IMiniportWaveRTInputStream::GetReadPacket

IMiniportWaveRTOutputStream

Ein WaveRT-Miniport implementiert optional diese Schnittstelle, um über den Schreibfortschritt vom Betriebssystem informiert zu werden und eine genaue Streamposition zurückzugeben. Weitere Informationen finden Sie unter IMiniportWaveRTOutputStream::SetWritePacket, IMiniportWaveRTOutputStream::GetOutputStreamPresentationPosition und IMiniportWaveRTOutputStream::GetPacketCount.

Zeitstempel des Leistungsindikators

Mehrere Der Treiberroutinen geben Windows-Leistungsindikatorzeitstempel zurück, die die Zeit widerspiegeln, zu der Beispiele vom Gerät erfasst oder angezeigt werden.

Bei Geräten mit komplexen DSP-Pipelines und signalisierter Signalverarbeitung kann die Berechnung eines genauen Zeitstempels eine Herausforderung sein und sollte sorgfältig durchgeführt werden. Die Zeitstempel sollten nicht einfach den Zeitpunkt widerspiegeln, zu dem Stichproben an oder vom Betriebssystem an den DSP übertragen wurden.

  • Verfolgen Sie innerhalb des DSP Beispielzeitstempel mithilfe einer internen DSP-Wanduhr.
  • Berechnen Sie zwischen dem Treiber und DSP eine Korrelation zwischen dem Windows-Leistungsindikator und der DSP-Wanduhr. Verfahren hierfür können von sehr einfachen (aber weniger präzisen) bis zu recht komplexen oder neuartigen (aber präziseren) reichen.
  • Berücksichtigen Sie konstante Verzögerungen aufgrund von Signalverarbeitungsalgorithmen oder Pipeline- oder Hardwaretransporten, es sei denn, diese Verzögerungen werden anderweitig berücksichtigt.

Burst-Lesevorgang

In diesem Abschnitt wird die Betriebssystem- und Treiberinteraktion für Burstlesevorgänge beschrieben. Burstlesevorgänge können außerhalb des Sprachaktivierungsszenarios erfolgen, solange der Treiber das paketbasierte Streaming-WaveRT-Modell unterstützt, einschließlich der IMiniportWaveRTInputStream::GetReadPacket-Funktion .

Es werden zwei Burst-Beispielleseszenarien erläutert. In einem Szenario unterstützt der Miniport einen Pin mit der Pinkategorie KSNODETYPE_AUDIO_KEYWORDDETECTOR beginnt der Treiber mit der Erfassung und internen Pufferung von Daten, wenn ein Schlüsselwort (keyword) erkannt wird. In einem anderen Szenario kann der Treiber optional Daten intern außerhalb des WaveRT-Puffers puffern, wenn das Betriebssystem Daten nicht schnell genug liest, indem IMiniportWaveRTInputStream::GetReadPacket aufgerufen wird.

Zum Bursten von Daten, die vor dem Übergang zu KSSTATE_RUN erfasst wurden, muss der Treiber genaue Beispielzeitstempelinformationen zusammen mit den gepufferten Erfassungsdaten beibehalten. Die Zeitstempel identifizieren den Stichprobenzeitpunkt der erfassten Stichproben.

  1. Nachdem der Stream zu KSSTATE_RUN übergeht, legt der Treiber sofort das Pufferbenachrichtigungsereignis fest, da bereits Daten verfügbar sind.

  2. Bei diesem Ereignis ruft das Betriebssystem GetReadPacket() auf, um Informationen zu den verfügbaren Daten abzurufen.

    a. Der Treiber gibt die Paketnummer der gültigen erfassten Daten zurück (0 für das erste Paket nach dem Übergang von KSSTATE_STOP zu KSSTATE_RUN), von denen das Betriebssystem die Paketposition innerhalb des WaveRT-Puffers sowie die Paketposition relativ zum Start des Datenstroms ableiten kann.

    b. Der Treiber gibt auch den Leistungsindikatorwert zurück, der dem Sampling-Instant des ersten Beispiels im Paket entspricht. Beachten Sie, dass dieser Leistungsindikatorwert relativ alt sein kann, je nachdem, wie viele Erfassungsdaten innerhalb der Hardware oder des Treibers (außerhalb des WaveRT-Puffers) gepuffert wurden.

    c. Wenn mehr ungelesene gepufferte Daten verfügbar sind, kann der Treiber entweder i. Überträgt diese Daten sofort in den verfügbaren Bereich des WaveRT-Puffers (d. h. speicherplatz, der von dem von GetReadPacket zurückgegebenen Paket nicht verwendet wird), gibt true für MoreData zurück und legt das Pufferbenachrichtigungsereignis fest, bevor von dieser Routine zurückgegeben wird. Oder, ii. Programmiert Hardware, um das nächste Paket in den verfügbaren Bereich des WaveRT-Puffers zu bursten, gibt false für MoreData zurück und legt später das Pufferereignis fest, wenn die Übertragung abgeschlossen ist.

  3. Das Betriebssystem liest Daten aus dem WaveRT-Puffer unter Verwendung der von GetReadPacket() zurückgegebenen Informationen.

  4. Das Betriebssystem wartet auf das nächste Pufferbenachrichtigungsereignis. Die Wartezeit wird möglicherweise sofort beendet, wenn der Treiber die Pufferbenachrichtigung in Schritt (2c) festgelegt hat.

  5. Wenn der Treiber das Ereignis in Schritt (2c) nicht sofort festgelegt hat, legt der Treiber das Ereignis fest, nachdem mehr erfasste Daten in den WaveRT-Puffer übertragen wurden, und stellt es für das Betriebssystem zum Lesen bereit.

  6. Wechseln Sie zu (2). Für KSNODETYPE_AUDIO_KEYWORDDETECTOR Schlüsselwort (keyword)-Pins sollten Treiber genügend interne Burstpufferung für mindestens 5000 ms Audiodaten zuweisen. Wenn das Betriebssystem vor dem Pufferüberlauf keinen Stream auf dem Pin erstellt, kann der Treiber die interne Pufferaktivität beenden und zugeordnete Ressourcen freigeben.

Wake on Voice

Wake On Voice (WoV) ermöglicht es dem Benutzer, eine Spracherkennungs-Engine von einem ausgeschalteten Bildschirm, einem niedrigeren Energiezustand bis zu einem bildschirm aktivierten, vollständigen Energiezustand zu aktivieren und abzufragen, indem er einen bestimmten Schlüsselwort (keyword) sagt, z. B. "Hey Cortana".

Dieses Feature ermöglicht es dem Gerät, immer auf die Stimme des Benutzers zu lauschen, während sich das Gerät in einem Energiesparmodus befindet, einschließlich, wenn der Bildschirm ausgeschaltet ist und sich das Gerät im Leerlauf befindet. Dazu wird ein Lauschmodus verwendet, der im Vergleich zu dem viel höheren Stromverbrauch bei normaler Mikrofonaufzeichnung niedriger ist. Die Spracherkennung mit geringer Leistung ermöglicht es einem Benutzer, einfach einen vordefinierten Schlüsselbegriff wie "Hey Cortana" zu sagen, gefolgt von einem verketteten Sprachbegriff wie "Wann ist mein nächster Termin", um Sprache freihändig aufzurufen. Dies funktioniert unabhängig davon, ob das Gerät verwendet wird oder bei ausgeschaltetem Bildschirm im Leerlauf ist.

Der Audiostapel ist für die Kommunikation der Aktivierungsdaten (Sprecher-ID, Schlüsselwort (keyword) Trigger, Konfidenzstufe) sowie für die Benachrichtigung interessierter Clients verantwortlich, dass die Schlüsselwort (keyword) erkannt wurde.

Validierung auf modernen Standbysystemen

WoV aus einem System im Leerlaufzustand kann auf Modernen Standbysystemen mit dem Modern Standby Wake on Voice Basic Test on AC-power Source und dem Modern Standby Wake on Voice Basic Test on DC-power Source im HLK überprüft werden. Diese Tests überprüfen, ob das System über einen Hardware-Schlüsselwort (keyword) Spotter (HW-KWS) verfügt, in den tiefsten Laufzeit-Idle Platform-Zustand (DRIPS) gelangen kann und aus dem Modernen Standbymodus auf Sprachbefehl mit einer Latenz von weniger als einer Sekunde reaktiviert werden kann.