Voice-Aktivierung

Hinweis

Dieses Thema bezieht sich in erster Linie auf unsere Anwenderfeatures, 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 Technologie des persönlichen Assistenten wurde erstmals auf der Microsoft BUILD Developer Conference im Jahr 2013 demonstriert. 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 ein Spracherkennungsmodul aus verschiedenen Geräteleistungszuständen aufrufen können, indem sie einen bestimmten Ausdruck sagen: „Hey Cortana“. Wenn Sie Hardware erstellen möchten, die die Sprachaktivierungstechnologie unterstützt, lesen Sie die Informationen in diesem Thema.

Hinweis

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

Cortana-Endbenutzererfahrung

Lesen Sie diese Themen, um die in Windows verfügbare Sprachinteraktion zu verstehen.

Thema	Beschreibung
Was ist Cortana?	Bietet einen Überblick und eine Nutzungsanleitung für Cortana

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

Sprachaktivierung „Hey Cortana“

Mit der Sprachaktivierungsfunktion „Hey Cortana“ (VA) können Benutzer die Cortana-Erfahrung außerhalb ihres aktiven Kontexts (d. h. was derzeit auf dem Bildschirm ist) mithilfe ihrer Stimme schnell einbinden. Benutzer möchten häufig sofort auf eine Oberfläche zugreifen können, ohne physisch mit einem Gerät interagieren zu müssen. Für Telefonnutzer kann dies daran liegen, dass sie im Auto fahren und ihre Aufmerksamkeit und Hände mit der Bedienung des Fahrzeugs beschäftigt sind. Für einen Xbox-Benutzer kann dies daran liegen, dass er keinen Controller finden und anschließen möchte. Für PC-Benutzer kann dies daran liegen, dass sie schnell auf ein Erlebnis zugreifen können, ohne mehrere Maus-, Berührungs- und/oder Tastaturaktionen ausführen zu müssen, z. B. ein Computer in der Küche.

Die Sprachaktivierung bietet immer Spracheingaben über vordefinierte Schlüsselsätze oder „Aktivierungsausdrücke“. Schlüsselphrasen können einzeln („Hey Cortana“) als inszenierter Befehl ausgesprochen werden oder von einer Sprachaktion gefolgt werden, zum Beispiel „Hey Cortana, wo findet meine nächste Besprechung statt?“, einem verketteten Befehl.

Der Begriff Schlüsselworterkennung beschreibt die Erkennung des Schlüsselworts entweder durch Hardware oder Software.

Die Aktivierung Nur Schlüsselwort erfolgt, wenn nur das Cortana-Schlüsselwort gesagt wird, Cortana startet und den EarCon-Sound wiedergibt, um anzuzeigen, dass der Hörmodus aktiviert wurde.

Ein verketteter Befehl beschreibt die Möglichkeit, unmittelbar nach dem Schlüsselwort einen Befehl auszugeben (z. B. „Hey Cortana, ruf John an“) und Cortana zu starten (falls nicht bereits gestartet) und dem Befehl zu folgen (ein Telefongespräch mit John zu beginnen).

Dieses Diagramm veranschaulicht die verkettete Aktivierung und die Nur-Schlüsselwort-Aktivierung.

Microsoft stellt eine standardmäßige Schlüsselworterkennung des Betriebssystems (Software-Schlüsselworterkennung) bereit, die verwendet wird, um die Qualität der Hardware-Schlüsselworterkennung sicherzustellen und das Hey Cortana-Erlebnis in Fällen bereitzustellen, in denen die Hardware-Schlüsselworterkennung fehlt oder nicht verfügbar ist.

Die Funktion „Meine Stimme lernen“

Mit der Funktion „Meine Stimme lernen“ kann der Benutzer Cortana trainieren, um seine eindeutige Stimme zu erkennen. Dazu wählt der Benutzer Erfahren Sie, wie ich „Hey Cortana“ sage im Cortana-Einstellungsbildschirm aus. Der Benutzer wiederholt dann sechs sorgfältig ausgewählte Phrasen, die eine ausreichende Vielfalt an phonetischen Mustern bieten, um die einzigartigen Merkmale der Stimme des Benutzers zu identifizieren.

Wenn die Sprachaktivierung mit „Meine Stimme lernen“ gekoppelt ist, arbeiten die beiden Algorithmen zusammen, um falsche Aktivierungen zu reduzieren. Dies ist besonders wertvoll für das Szenario eines Besprechungsraums, bei dem eine Person in einem Raum voller Geräte „Hey Cortana“ sagt. Dieses Feature ist nur für Windows 10, Version 1903 und früher verfügbar.

Die Sprachaktivierung erfolgt durch eine Schlüsselworterkennung (Keyword Spotter, KWS) die reagiert, wenn die Schlüsselphrase erkannt wird. Wenn die Schlüsselworterkennung das Gerät aus einem Energiesparzustand aufwecken soll, wird die Lösung als Wake on Voice (WoV) bezeichnet. Weitere Informationen finden Sie unter Wake on Voice.

Glossar der Begriffe

In diesem Glossar werden Begriffe im Zusammenhang mit der Sprachaktivierung zusammengefasst.

Begriff	Beispiel/Definition
Mehrstufiger Befehl	Beispiel: Hey Cortana <Pause, warten auf Earcon> Wie ist das Wetter? 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 der Schlüsselworterkennung einer vordefinierten Aktivierungsschlüsselphrase. „Hey Cortana“ ist beispielsweise das Microsoft-Sprachaktivierungsszenario.
WoV	Wake-on-Voice – Technologie, die die Sprachaktivierung von einem ausgeschalteten Bildschirm mit geringerer Leistung bis zu einem Bildschirm mit voller Leistung ermöglicht.
WoV aus dem modernen Standbymodus	Wake-on-Voice aus einem modernen Standbybildschirm (S0ix) in einen Bildschirm im Vollbetriebszustand (S0).
Moderner Standbymodus	Windows Low Power Idle-Infrastruktur – Nachfolger von Connected Standby (CS) in Windows 10. Der erste Status des modernen Standbymodus ist, wenn der Bildschirm deaktiviert ist. Der tiefste Ruhezustand ist im DRIPS/Resilienz-Modus. Weitere Informationen finden Sie unter Moderner Standbymodus.
KWS	Schlüsselworterkennung – der Algorithmus, der die Erkennung von „Hey Cortana“ bereitstellt
SW KWS	Software-Schlüsselworterkennung – eine Implementierung von KWS, die auf dem Host (CPU) ausgeführt wird. Für „Hey Cortana“ ist SW KWS im Rahmen von Windows enthalten.
HW KWS	Hardware-ausgelagerte Schlüsselworterkennung – eine Implementierung der Schlüsselworterkennung, die ausgelagert auf Hardware läuft.
Burst-Puffer	Ein Ringpuffer zum Speichern von PCM-Daten, der im Falle einer Schlüsselworterkennung „ausbrechen“ kann, sodass alle Audiodaten, die eine Schlüsselworterkennung ausgelöst haben, enthalten sind.
OEM-Adapter für Schlüsselwortdetektor	Ein Shim auf Treiberebene, mit dem die WoV-fähige HW mit Windows und dem Cortana-Stapel kommunizieren kann.
Modell	Die vom KWS-Algorithmus verwendete Akustikmodelldatendatei. Die Datendatei ist statisch. Modelle werden lokalisiert, eine pro Gebietsschema.

Integrieren einer Hardware-Schlüsselworterkennung

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

• Erstellen Sie einen benutzerdefinierten Schlüsselwortdetektor basierend auf dem SYSVAD-Beispiel, das später in diesem Thema beschrieben wird. Sie implementieren diese Methoden in einer COM-DLL, die in OEM-Adapter für Schlüsselwortdetektor beschrieben wird.
• Implementieren Sie WAVE RT-Verbesserungen, die in WAVERT-Verbesserungen beschrieben sind.
• Stellen Sie INF-Dateieinträge bereit, um benutzerdefinierte APOs zu beschreiben, die für die Schlüsselworterkennung verwendet werden.
  • 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
• Überprüfen Sie die Hardwareempfehlungen und Testanleitungen in Empfehlung für Audiogeräte. Dieses Thema enthält Anleitungen und Empfehlungen für den Entwurf und die Entwicklung von Audioeingabegeräten, die für die Verwendung mit der Speech Platform von Microsoft vorgesehen sind.
• Unterstützung für sowohl mehrstufige als auch verkettete Befehle.
• Unterstützung von „Hey Cortana“ für jedes der unterstützten Cortana-Gebietsschemas.
• Die APOs (Audio Processing Objects) müssen die folgenden Effekte bereitstellen:
  • AEC
  • AGC
  • NS
• Effekte für den Sprachverarbeitungsmodus müssen vom MFX-APO gemeldet werden.
• Das APO kann eine Formatkonvertierung als MFX durchführen.
• Die APO muss das folgende Format ausgeben:
  • 16 kHz, Mono, FLOAT.
• Entwerfen Sie optional alle benutzerdefinierten APOs, um den Audioerfassungsprozess zu verbessern. Weitere Informationen finden Sie unter Windows-Audioverarbeitungsobjekte.

WoV-Anforderungen für Hardware-ausgelagerte Schlüsselworterkennung

• HW KWS WoV wird während des S0-Betriebszustands und des S0-Ruhezustands unterstützt, der auch als moderner Standbymodus 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 S0-Ruhezustand (moderner Standbymodus) ist AEC nicht erforderlich.
  • HW KWS WoV für S0-Betriebszustand wird in Windows Version 1709 nicht unterstützt.

• Für Windows-Version 1803

  • HW KWS WoV für S0-Betriebszustand wird unterstützt.
  • Um HW KWS WoV für den S0-Betriebszustand zu aktivieren, muss die APO AEC unterstützen.

Übersicht über das Codebeispiel

Es gibt Beispielcode für einen Audiotreiber, der die Sprachaktivierung auf GitHub als Teil des Beispiels für den virtuellen Audioadapter SYSVAD 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-Beispielaudiotreiber finden Sie unter Beispielaudiotreiber.

Informationen zum Schlüsselworterkennungssystem

Unterstützung für Sprachaktivierungs-Audiostapel

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

• Gerätetreiberschnittstelle (DDI) für Schlüsselwortdetektor Die Gerätetreiberschnittstelle für den Schlüsselwortdetektor ist für die Konfiguration und Aktivierung der Hardware-Schlüsselworterkennung (HW Keyword Spotter, KWS) verantwortlich. Sie wird auch vom Treiber verwendet, um das System über ein Erkennungsereignis zu benachrichtigen.
• OEM-Adapter-DLL für den Schlüsselwortdetektor. Diese DLL implementiert eine COM-Schnittstelle, um die treiberspezifischen nicht transparenten Daten für die Verwendung durch das Betriebssystem anzupassen und die Schlüsselworterkennung zu unterstützen.
• WaveRT-Streamingverbesserungen. Die Verbesserungen ermöglichen es dem Audiotreiber, die gepufferten Audiodaten aus der Schlüsselworterkennung im Burst-Stream zu streamen.

Audioendpunkteigenschaften

Das Erstellen von Audioendpunktdiagrammen erfolgt normal. Das Diagramm ist für eine schnellere Verarbeitung als bei der Echtzeiterfassung vorbereitet. Zeitstempel auf erfassten Puffern bleiben erhalten. Insbesondere spiegeln die Zeitstempel korrekt Daten wider, die in der Vergangenheit erfasst und zwischengespeichert wurden und jetzt „überlastet“ sind.

Theorie der Bluetooth-Umgehung von Audiostreaming

Der Treiber stellt wie gewohnt einen KS-Filter für sein Erfassungsgerät bereit. 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üsselworterkennungs-PIN (KWS) identifiziert wird. Dieser Pin wird verwendet, um Audio aus der Schlüsselworterkennung zu streamen.

Dabei handelt es sich um die folgenden Eigenschaften:

• Unterstützte Schlüsselworttypen – KSPROPERTY_SOUNDDETECTOR_PATTERNS. Diese Eigenschaft wird vom Betriebssystem festgelegt, um die zu erkennenden Schlüsselwörter zu konfigurieren.
• Liste der Schlüsselwort-Muster-GUIDs – KSPROPERTY_SOUNDDETECTOR_SUPPORTEDPATTERNS. Diese Eigenschaft wird verwendet, um eine Liste von GUIDs abzurufen, die die Typen der unterstützten Muster identifizieren.
• Aktiviert – KSPROPERTY_SOUNDDETECTOR_ARMED. Diese Lese-/Schreibeigenschaft ist ein einfach boolescher Status, der angibt, ob der Detektor aktiviert ist. Das Betriebssystem stellt dies so ein, dass der Schlüsselwortdetektor aktiviert wird. Das Betriebssystem kann dies löschen, um dies zu deaktivieren. Der Treiber löscht dies automatisch, wenn Schlüsselwortmuster festgelegt werden und auch nachdem ein Schlüsselwort erkannt wurde. (Das Betriebssystem muss neu aktiviert werden.)
• Abgleichsergebnis – KSPROPERTY_SOUNDDETECTOR_MATCHRESULT. Diese Leseeigenschaft enthält die Ergebnisdaten nach erfolgter Erkennung.

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

Abfolge der Vorgänge

Systemstart

1. Das Betriebssystem liest die unterstützten Schlüsselworttypen, um zu überprüfen, ob Schlüsselwörter in diesem Format vorhanden sind.
2. Das Betriebssystem registriert sich für das Statusänderungsereignis des Detektors.
3. Das Betriebssystem legt die Schlüsselwortmuster fest.
4. Das Betriebssystem aktiviert den Detektor.

Beim Empfangen des KS-Ereignisses

1. Der Treiber deaktiviert den Detektor.
2. Das Betriebssystem liest den Status des Schlüsselwortdetektors, analysiert die zurückgegebenen Daten und bestimmt, welches Muster erkannt wurde.
3. Das Betriebssystem aktiviert den Detektor erneut.

Interner Treiber- und Hardwarebetrieb

Während der Detektor aktiviert ist, kann die Hardware kontinuierlich Audiodaten erfassen und in einem kleinen FIFO-Puffer puffern. (Die Größe dieses FIFO-Puffers wird durch Anforderungen außerhalb dieses Dokuments bestimmt, kann jedoch typischerweise Hunderte von Millisekunden bis mehrere Sekunden betragen.) Der Erkennungsalgorithmus arbeitet mit den Daten, die durch diesen Puffer strömen. Das Design des Treibers und der Hardware ist so ausgelegt, dass im aktivierten Zustand keine Interaktion zwischen dem Treiber und der Hardware und keine Unterbrechungen der „Anwendungs“-Prozessoren stattfinden, bis ein Schlüsselwort erkannt wird. Dadurch kann das System einen niedrigeren Energiezustand erreichen, wenn keine andere Aktivität stattfindet.

Wenn die Hardware ein Schlüsselwort erkennt, generiert sie eine Unterbrechung. Während sie darauf wartet, dass der Treiber die Unterbrechung bedient, erfasst die Hardware weiterhin Audio im Puffer und stellt so sicher, dass innerhalb der Puffergrenzen keine Daten verloren gehen, nachdem das Schlüsselwort verloren gegangen ist.

Schlüsselwort-Zeitstempel

Nach der Erkennung eines Schlüsselworts müssen alle Sprachaktivierungslösungen das gesamte gesprochene Schlüsselwort puffern, einschließlich 250 ms vor dem Beginn des Schlüsselworts. Der Audiotreiber muss Zeitstempel bereitstellen, die den Anfang und das Ende der Schlüsselphrase im Stream identifizieren.

Um die Schlüsselwort-Start-/Endzeitstempel zu unterstützen, muss die DSP-Software möglicherweise Ereignisse basierend auf einer DSP-Uhr intern mit einem Zeitstempel versehen. Sobald ein Schlüsselwort erkannt wird, interagiert die DSP-Software mit dem Treiber, um ein KS-Ereignis vorzubereiten. Der Treiber und die DSP-Software müssen den DSP-Zeitstempel einem Windows-Leistungsindikatorwert zuordnen. Die Methode hierfür ist spezifisch für das Hardwaredesign. 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. Anhand der Korrelation kann der Treiber dann die Schlüsselwort-DSP-Zeitstempel den Zeitstempeln des Windows-Leistungsindikators zuordnen.

OEM-Adapterschnittstelle für Schlüsselwortdetektor

Der OEM stellt eine COM-Objektimplementierung bereit, die als Vermittler zwischen dem Betriebssystem und dem Treiber fungiert und dabei hilft, die nicht transparenten 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 von 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 dem Schlüsselwortmustertyp kompatibel ist, und ruft Methoden für die IKeywordDetectorOemAdapter-Schnittstelle des Objekts auf.

Anforderungen an das COM-Threading-Modell

Die OEM-Implementierung kann eines der COM-Threading-Modelle wählen.

IKeywordDetectorOemAdapter

Das Schnittstellendesign versucht, die Objektimplementierung zustandslos zu halten. Mit anderen Worten: Die Implementierung sollte erfordern, dass zwischen Methodenaufrufen kein Status gespeichert wird. Tatsächlich benötigen interne C++-Klassen wahrscheinlich keine Membervariablen, die über die hinausgehen, die für die Implementierung eines COM-Objekts im Allgemeinen erforderlich sind.

Methoden

Implementieren Sie die folgenden Methoden.

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

KEYWORDID

Die KEYWORDID-Aufzählung identifiziert den Ausdruckstext/die Funktion eines Schlüsselworts und wird auch in den Windows Biometric Service-Adaptern verwendet. Weitere Informationen finden Sie in Übersicht über biometrisches Framework – Kernplattformkomponenten

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

KEYWORDSELECTOR

Die KEYWORDSELECTOR-Struktur ist eine Reihe von IDs, die ein bestimmtes Schlüsselwort und die Sprache eindeutig auswählen.

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

Behandeln von Modelldaten

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

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

Der Inhalt und die Struktur der Daten innerhalb dieses Speichers wird 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 ruft die Schnittstellenmethoden möglicherweise mit einem leeren IStream auf, insbesondere wenn der Benutzer noch nie ein Schlüsselwort trainiert hat. Das Betriebssystem erstellt einen separaten IStream-Speicher für jeden Benutzer. Mit anderen Worten: Ein bestimmter IStream speichert Modelldaten für einen und nur einen Benutzer.

Der OEM DLL-Entwickler entscheidet, wie die benutzerunabhängigen und benutzerabhängigen Daten verwaltet werden. Benutzerdaten dürfen jedoch niemals außerhalb des IStream gespeichert werden. Ein mögliches OEM-DLL-Design würde abhängig von den Parametern der aktuellen Methode intern zwischen dem Zugriff auf den IStream und die statischen benutzerunabhängigen Daten wechseln. Ein alternatives Design könnte den IStream zu Beginn jedes Methodenaufrufs überprüfen und die statischen benutzerunabhängigen Daten zum IStream hinzufügen, sofern diese nicht bereits vorhanden sind, sodass der Rest der Methode nur auf den IStream für alle Modelldaten zugreifen kann.

Schulungs- und Betriebsaudioverarbeitung

Wie zuvor beschrieben, führt der Trainings-UI-Flow dazu, dass vollständige phonetisch reichhaltige Sätze im Audiostream verfügbar sind. Jeder Satz wird einzeln an IKeywordDetectorOemAdapter::VerifyUserKeyword übergeben, um sicherzustellen, dass er das erwartete Schlüsselwort enthält und über eine akzeptable Qualität verfügt. Nachdem alle Sätze von der Benutzeroberfläche gesammelt und überprüft wurden, werden sie alle in einem Aufruf an IKeywordDetectorOemAdapter::ComputeAndAddUserModelData übergeben.

Audio wird auf einzigartige Weise für das Sprachaktivierungstraining verarbeitet. Die folgende Tabelle fasst die Unterschiede zwischen dem Sprachaktivierungstraining und der regulären Verwendung der Spracherkennung zusammen.

|

	Sprachtraining	Spracherkennung
Mode	Raw	Unformatiert oder Sprache
Pin	Normal	KWS
Audioformat	32-Bit-Float (Typ = Audio, Untertyp = IEEE_FLOAT, Samplingrate = 16 kHz, Bits = 32)	Vom Betriebssystem-Audiostapel verwaltet
Mikrofon	Mikrofon 0	Alle Mikrofone im Array oder Mono

Übersicht über das Schlüsselworterkennungssystem

Dieses Diagramm bietet eine Übersicht über das Schlüsselworterkennungssystem.

Sequenzdiagramme zur Schlüsselworterkennung

In diesen Diagrammen wird das Sprachlaufzeitmodul als „Sprachplattform“ angezeigt. Wie bereits erwähnt, wird die Windows-Sprachplattform verwendet, um alle Spracherlebnisse in Windows 10 wie Cortana und Diktieren zu ermöglichen.

Während des Starts werden Funktionen mithilfe von IKeywordDetectorOemAdapter::GetCapabilities gesammelt.

Wenn der Benutzer später „Meine Stimme lernen“ auswählt, wird der Trainingsflow aufgerufen.

Dieses Diagramm beschreibt den Prozess der Aktivierung zur Schlüsselworterkennung.

WAVERT-Verbesserungen

Miniport-Schnittstellen werden definiert, die von WaveRT-Miniporttreibern implementiert werden sollen. Diese Schnittstellen bieten Methoden, um entweder den Audiotreiber zu vereinfachen, die Leistung und Zuverlässigkeit der Betriebssystem-Audiopipeline zu verbessern oder neue Szenarien zu unterstützen. Es wurde eine neue Eigenschaft der PnP-Geräteschnittstelle definiert, die es dem Treiber ermöglicht, dem Betriebssystem statische Ausdrücke seiner Puffergrößenbeschränkungen bereitzustellen.

Puffergrößen

Beim Verschieben von Audiodaten zwischen dem Betriebssystem, dem Treiber und der Hardware unterliegt ein Treiber verschiedenen Einschränkungen. Diese Einschränkungen können auf den physischen Hardwaretransport zurückzuführen sein, der Daten zwischen Speicher und Hardware bewegt, und/oder auf die Signalverarbeitungsmodule innerhalb der Hardware oder des zugehörigen DSP.

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

Der Treiber drückt die Puffergrößenbeschränkungen aus, indem er die Geräteeigenschaft DEVPKEY_KsAudio_PacketSize_Constraints auf der PnP-Geräteschnittstelle KSCATEGORY_AUDIO des KS-Filters festlegt, der über die KS-Streaming-Pins verfügt. Diese Eigenschaft sollte gültig und stabil bleiben, während die KS-Filterschnittstelle aktiviert ist. Das Betriebssystem kann diesen Wert jederzeit lesen, ohne dass ein Handle für den Treiber geöffnet und der Treiber aufgerufen werden muss.

DEVPKEY_KsAudio_PacketSize_Constraints

Der Wert der DEVPKEY_KsAudio_PacketSize_Constraints-Eigenschaft enthält eine KSAUDIO_PACKETSIZE_CONSTRAINTS-Struktur, die die physischen Hardwarebeschränkungen beschreibt (d. h. aufgrund der Mechanismen der Datenübertragung vom WaveRT-Puffer zur Audio-Hardware). Die Struktur enthält ein Array von 0 oder mehr 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 die KS-Filterschnittstelle für seine Streaming-Pins aktiviert wird.

IMiniportWaveRTInputStream

Ein Treiber implementiert diese Schnittstelle zur besseren Koordinierung des Audio-Dataflows vom Treiber zum Betriebssystem. Wenn diese Schnittstelle in einem Erfassungs-Stream verfügbar ist, verwendet das Betriebssystem Methoden auf dieser Schnittstelle, um auf Daten im WaveRT-Puffer zuzugreifen. Weitere Informationen finden Sie unter IMiniportWaveRTInputStream::GetReadPacket

IMiniportWaveRTOutputStream

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

Leistungsindikator-Zeitstempel

Mehrere der Treiberroutinen geben Zeitstempel des Windows-Leistungsindikators zurück, die den Zeitpunkt widerspiegeln, zu dem Beispiele vom Gerät erfasst oder präsentiert werden.

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

• Verfolgen Sie im DSP Beispielzeitstempel mit einigen internen DSP-Gesamtbetrachtungen.
• Berechnen Sie zwischen dem Treiber und dem DSP eine Korrelation zwischen dem Windows-Leistungsindikator und der DSP-Gesamtbetrachtung. Die Verfahren hierfür können von sehr einfach (aber weniger präzise) bis hin zu ziemlich komplex oder neuartig (aber präziser) reichen.
• Berücksichtigen Sie etwaige ständige Verzögerungen aufgrund von Signalverarbeitungsalgorithmen oder Pipeline- oder Hardwaretransporten, sofern diese Verzögerungen nicht anderweitig berücksichtigt werden.

Burst-Lesevorgang

In diesem Abschnitt wird die Interaktion zwischen Betriebssystem und Treiber für Burst-Lesevorgänge beschrieben. Der Burst-Lesevorgang kann außerhalb des Sprachaktivierungsszenarios erfolgen, solange der Treiber das paketbasierte Streaming-WaveRT-Modell unterstützt, einschließlich der IMiniportWaveRTInputStream::GetReadPacket-Funktion.

Es werden zwei Beispiel-Leseszenarien erörtert. Wenn der Miniport in einem Szenario einen Pin mit der Pin-Kategorie KSNODETYPE_AUDIO_KEYWORDDETECTOR unterstützt, beginnt der Treiber mit der Erfassung und internen Pufferung von Daten, wenn ein Schlüsselwort erkannt wird. In einem anderen Szenario kann der Treiber optional Daten außerhalb des WaveRT-Puffers intern puffern, wenn das Betriebssystem die Daten durch den Aufruf von IMiniportWaveRTInputStream::GetReadPacket nicht schnell genug liest.

Um vor dem Übergang zu KSSTATE_RUN erfasste Daten aufzuteilen, muss der Treiber zusammen mit den gepufferten Erfassungsdaten genaue Zeitstempelinformationen des Beispiels beibehalten. Die Zeitstempel identifizieren den Zeitpunkt der Stichprobennahme der erfassten Beispiele.

1. Nach dem Übergang des Streams zu KSSTATE_RUN 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), aus der das Betriebssystem die Paketposition im WaveRT-Puffer sowie die Paketposition relativ zum Start des Streams ableiten kann.

   b. Der Treiber gibt außerdem den Leistungsindikatorwert zurück, der dem Zeitpunkt der Stichprobennahme der ersten Stichprobe im Paket entspricht. Beachten Sie, dass dieser Leistungsindikatorwert relativ alt sein kann, abhängig davon, wie viele Erfassungsdaten in der Hardware oder im Treiber (außerhalb des WaveRT-Puffers) gepuffert wurden.

   c. Wenn mehr ungelesene gepufferte Daten verfügbar sind, kann der Treiber entweder: i. diese Daten sofort in den verfügbaren Speicherplatz des WaveRT-Puffers übertragen (d. h. in den Speicherplatz, der nicht von dem von GetReadPacket zurückgegebenen Paket verwendet wird), „true“ für MoreData zurückgeben und das Pufferbenachrichtigungsereignis festlegen, bevor von dieser Routine zurückgekehrt wird. oder ii. Hardware programmieren, so dass er das nächste Paket in den verfügbaren Speicherplatz des WaveRT-Puffers auslagert, „false“ für MoreData zurückgeben und später das Pufferereignis festlegen, wenn die Übertragung abgeschlossen ist.

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

4. Das Betriebssystem wartet auf das nächste Pufferbenachrichtigungsereignis. Das Warten 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 er weitere erfasste Daten in den WaveRT-Puffer übertragen und sie dem Betriebssystem zum Lesen zur Verfügung gestellt hat.

6. Navigieren Sie zu (2). Für KSNODETYPE_AUDIO_KEYWORDDETECTOR-Schlüsselwortdetektor-Pins sollten Treiber genügend interne Burst-Puffer für mindestens 5000 ms Audiodaten zuordnen. Wenn das Betriebssystem keinen Stream auf dem Pin erstellen kann, bevor der Puffer überläuft, beendet der Treiber möglicherweise die interne Pufferaktivität und gibt zugehörige Ressourcen frei.

Wake on Voice

Wake On Voice (WoV) ermöglicht es dem Benutzer, ein Spracherkennungs-Modul zu aktivieren und abzufragen, indem er ein bestimmtes Schlüsselwort sagt, z. B. „Hey Cortana“.

Diese Funktion ermöglicht es dem Gerät, immer auf die Stimme des Benutzers zu hören, während sich das Gerät in einem Energiesparmodus befindet, auch wenn der Bildschirm ausgeschaltet ist und sich das Gerät im Leerlauf befindet. Dies geschieht durch die Verwendung eines Hörmodus, der im Vergleich zum viel höheren Stromverbrauch bei normaler Mikrofonaufnahme einen geringeren Stromverbrauch aufweist. Die Spracherkennung mit geringem Stromverbrauch ermöglicht es einem Benutzer, einfach einen vordefinierten Schlüsselsatz wie „Hey Cortana“ zu sagen, gefolgt von einem verketteten Sprachsatz wie „Wann ist meine nächste Besprechung“, um die 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 Übermittlung der Aktivierungsdaten (Sprecher-ID, Schlüsselwort-Trigger, Konfidenzniveau) sowie für die Benachrichtigung interessierter Clients über die Erkennung des Schlüsselworts verantwortlich.

Überprüfung auf modernen Standbysystemen

WoV aus einem System-Leerlaufzustand kann auf modernen Standby-Systemen mit dem einfachen Sprachaktivierungstest für modernen Standbymodus bei Wechselstromquellen und dem einfachen Sprachaktivierungstest für modernen Standbymodus bei Gleichstromquellen im HLK überprüft werden. Bei diesen Tests wird überprüft, ob das System über eine Hardware-Schlüsselworterkennung (HW-KWS) verfügt, in den Deepest Runtime Idle Platform State (DRIPS) wechseln kann und auf Sprachbefehl mit einer Systemwiederaufnahmelatenz von weniger als oder gleich einer Sekunde aus dem modernen Standbymodus reaktiviert werden kann.