Voice-Aktivierung

Hinweis

Dieses Thema bezieht sich hauptsächlich auf unsere Verbrauchererfahrungen, die derzeit in Windows 10 (Version 1909 und früher) bereitgestellt werden.

Cortana wurde die persönliche Assistenttechnologie zum ersten Mal in der Microsoft BUILD Developer Conference 2013 gezeigt. Die Windows Sprachplattform wird verwendet, um alle Spracherfahrungen in Windows 10 wie Cortana und Diktieren zu nutzen. Die Sprachaktivierung ist ein Feature, mit dem Benutzer ein Spracherkennungsmodul aus verschiedenen Geräteleistungszuständen aufrufen können, indem sie einen bestimmten Ausdruck - "Hey Cortana" sagen. Um Hardware zu erstellen, die Sprachaktivierungstechnologie unterstützt, lesen Sie die Informationen in diesem Thema.

Hinweis

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

Cortana Endbenutzerumgebung

Um die in Windows verfügbaren Sprachinteraktionserfahrung zu verstehen, lesen Sie diese Themen.

Thema BESCHREIBUNG
Was ist Cortana? Bietet eine Übersicht und Nutzungsrichtung für Cortana
Machen Sie Cortana Ihre Beschreibt die Anpassung, die über Cortana Einstellungen Bildschirme verfügbar ist.

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

Hey Cortana" Sprachaktivierung

Mit der Funktion "Hey Cortana" voice activation (VA) können Benutzer schnell die Cortana Erfahrung außerhalb ihres aktiven Kontexts (d. h., was derzeit auf dem Bildschirm ist) mithilfe ihrer Stimme interagieren. Benutzer möchten häufig sofort auf eine Erfahrung zugreifen, ohne physisch mit einem Gerät zu interagieren. Für Telefonbenutzer kann dies aufgrund des Fahrens im Auto sein und ihre Aufmerksamkeit und Hände mit dem Betrieb des Fahrzeugs beschäftigt sein. Für einen Xbox-Benutzer ist dies möglicherweise darauf zurückzuführen, dass ein Controller nicht gefunden und verbunden werden soll. Für PC-Benutzer kann dies auf einen schnellen Zugriff auf eine Erfahrung zurückzuführen sein, ohne mehrere Maus-, Touch- und/oder Tastaturaktionen auszuführen, z. B. einen Computer in der Küche.

Die Sprachaktivierung bietet immer Spracheingaben über vordefinierte Schlüsselausdrücke oder "Aktivierungsausdrücke". Schlüsselausdrücke können von sich selbst ("Hey Cortana") als schrittweiser Befehl oder gefolgt von einer Sprachaktion, z. B. "Hey Cortana, wo ist meine nächste Besprechung?", ein verketteter Befehl.

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

Schlüsselwort tritt nur auf, wenn nur das Cortana Schlüsselwort gesagt wird, Cortana startet und den EarCon-Sound wiedergegeben, um anzugeben, dass er den Hörmodus eingegeben hat.

Ein verketteter Befehl beschreibt die Möglichkeit, einen Befehl unmittelbar nach dem Schlüsselwort (z. B. "Hey Cortana, Anruf John") auszugeben und Cortana den Befehl (wenn noch nicht gestartet) zu starten und den Befehl zu befolgen (ab einem Telefonanruf mit John).

Dieses Diagramm veranschaulicht nur die verkettete und Schlüsselwortaktivierung.

chained and keyword activation diagram showing audio buffer and time sequence.

Microsoft stellt einen Betriebssystem-Standard-Schlüsselwort-Spotter (Software-Schlüsselwort-Spotter) bereit, der verwendet wird, um die Qualität der Hardwareschlüsselworterkennungen sicherzustellen und die Hey Cortana-Erfahrung in Fällen bereitzustellen, in denen die Hardwareworterkennung nicht vorhanden oder nicht verfügbar ist.

Das Feature "Meine Stimme lernen"

Mit der Funktion "Meine Stimme lernen" können Benutzer Cortana trainieren, um ihre eindeutige Stimme zu erkennen. Dies wird vom Benutzer durchgeführt, der im Bildschirm Cortana Einstellungen "Hey Cortana" sagt. Der Benutzer wiederholt dann sechs sorgfältig ausgewählte Ausdrücke, die eine ausreichende Vielzahl von phonetischen Mustern bieten, um die eindeutigen Attribute der Stimme der Benutzer zu identifizieren.

cortana desktop settings for hw keyword spotter wake on voice.

Wenn die Sprachaktivierung mit "Meine Stimme lernen" gekoppelt ist, funktionieren die beiden Algorithmen zusammen, um falsche Aktivierungen zu reduzieren. Dies ist besonders nützlich 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 von einem Schlüsselwort-Spotter (KWS) unterstützt, der reagiert, wenn der Schlüsselausdruck erkannt wird. Wenn die KWS das Gerät von einem niedrig unterstützten Zustand aufaktivieren 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
Befehl "Stufen" Beispiel: Hey Cortana <Anhalten, warten Sie auf Earcon> Was ist das Wetter? Dies wird manchmal als "Zwei-Schuss-Befehl" oder "Schlüsselwort-only" bezeichnet.
Verketteter Befehl Beispiel: Hey Cortana was ist das Wetter? Dies wird manchmal als "One-Shot-Befehl" bezeichnet.
Voice-Aktivierung Das Szenario der Bereitstellung der Schlüsselworterkennung einer vordefinierten Aktivierungstaste. Beispielsweise ist "Hey Cortana" das Microsoft Voice-Aktivierungsszenario.
WoV Wake-on-Voice – Technologie, mit der Die Sprachaktivierung von einem Bildschirm aus, niedrigerer Leistungszustand, auf einem Bildschirm auf einem Vollleistungszustand aktiviert wird.
WoV von Modern Standby Wake-on-Voice von einem Modernen Standby-Bildschirm (S0ix) auf einem Bildschirm mit voller Leistung (S0) aus.
Moderner Standby-Modus Windows Low Power Idle-Infrastruktur – Nachfolger von Connected Standby (CS) in Windows 10. Der erste Zustand des modernen Standbymodus ist, wenn der Bildschirm deaktiviert ist. Der tiefste Schlafzustand ist bei DRIPS/Resilienz. Weitere Informationen finden Sie unter Modern Standby
KWS Schlüsselwort-Fleck – der Algorithmus, der die Erkennung von "Hey Cortana" bereitstellt.
SW KWS Software-Schlüsselwort-Spotter – eine Implementierung von KWS, die auf dem Host (CPU) ausgeführt wird. Für "Hey Cortana" ist SW KWS als Teil Windows enthalten.
HW KWS Hardwarebeladener Schlüsselwort-Spotter – eine Implementierung von KWS, die auf Hardware geladen wird.
Platzpuffer Ein kreisförmiger Puffer, der zum Speichern von PCM-Daten verwendet wird, die im Falle einer KWS-Erkennung "geplatzt" werden können, sodass alle Audiodaten, die eine KWS-Erkennung ausgelöst haben, enthalten sind.
Schlüsselwortdetektor-OEM-Adapter Ein Treiberebenen-Shim, mit dem der WoV-aktivierte 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 eines Hardware-Schlüsselwort-Spotters

Um einen Hardware-Schlüsselwort-Spotter (HW KWS) SoC-Anbieter zu implementieren, müssen die folgenden Aufgaben abgeschlossen werden.

Hardware-offladene Schlüsselwort-Spotter (HW KWS) WoV-Anforderungen

  • HW KWS WoV wird während des S0 Working State und S0 Sleep State auch als Modern Standby bezeichnet.
  • HW KWS WoV wird von S3 nicht unterstützt.

AEC-Anforderungen für HW KWS

  • Für Windows Version 1709

    • Um HW KWS WoV für S0-Schlafzustand (Modern Standby) zu unterstützen, ist AEC nicht erforderlich.
    • HW KWS WoV für S0 Arbeitsstatus wird in Windows Version 1709 nicht unterstützt.
  • Für Windows Version 1803

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

Beispielcodeübersicht

Es gibt Beispielcode für einen Audiotreiber, der die Sprachaktivierung auf GitHub als Teil des Beispiels für virtuelle 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 Beispiel-Audiotreiber.

Schlüsselworterkennung Systeminformationen

Unterstützung für Sprachaktivierungs-Audiostapel

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

  • Schlüsselwortdetektor-Gerätetreiberschnittstelle (DDI) Die Schlüsselwortdetektor-Gerätetreiberschnittstelle ist für das Konfigurieren und Armieren des HW-Schlüsselwort-Spotters (KWS) verantwortlich. Es wird auch vom Treiber verwendet, um das System eines Erkennungsereigniss zu benachrichtigen.
  • Schlüsselwortdetektor-OEM-Adapter-DLL. Diese DLL implementiert eine COM-Schnittstelle, um die treiberspezifischen undurchsichtigen Daten für die Verwendung des Betriebssystems anzupassen, um die Schlüsselworterkennung zu unterstützen.
  • WaveRT-Streamingverbesserungen. Die Verbesserungen ermöglichen dem Audiotreiber, den gepufferten Audiodaten aus der Schlüsselworterkennung zu streamen.

Audioendpunkteigenschaften

Das Erstellen von Audioendpunktdiagrammen tritt normalerweise auf. Das Diagramm ist bereit, schneller als die Echtzeitaufnahme zu behandeln. Zeitstempel für erfasste Puffer bleiben wahr. Insbesondere werden die Zeitstempel korrekt Daten widerspiegeln, die in der Vergangenheit erfasst wurden und gepuffert wurden, und ist jetzt "bursting".

Theorie des Vorgangs

Der Treiber macht einen KS-Filter für sein Aufnahmegerät wie gewohnt verfügbar. Dieser Filter unterstützt mehrere KS-Eigenschaften und ein KS-Ereignis, um ein Erkennungsereignis zu konfigurieren, zu aktivieren und zu signalisieren. Der Filter enthält auch eine zusätzliche Pin-Fabrik, die als Schlüsselwort-Flecker (KWS) pin identifiziert wird. Diese Pin wird verwendet, um Audio aus dem Schlüsselwort-Spotter 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üsselwortmuster-GUIDs – KSPROPERTY_SOUNDDETECTOR_SUPPORTEDPATTERNS. Diese Eigenschaft wird verwendet, um eine Liste von GUIDs abzurufen, die die Typen von unterstützten Mustern identifizieren.
  • Bewaffnete - KSPROPERTY_SOUNDDETECTOR_ARMED. Diese Lese-/Schreibeigenschaft ist ein einfach boolescher Status, der angibt, ob der Detektor bewaffnet ist. Das Betriebssystem legt dies fest, um den Schlüsselwortdetektor zu aktivieren. Das Betriebssystem kann dies löschen, um dies zu deaktivieren. Der Treiber löscht dies automatisch, wenn Schlüsselwortmuster festgelegt werden und auch nach der Erkennung eines Schlüsselworts. (Das Betriebssystem muss neu angeordnet werden.)
  • Ergebnis übereinstimmen – KSPROPERTY_SOUNDDETECTOR_MATCHRESULT. Diese Leseeigenschaft enthält die Ergebnisdaten nach der Erkennung.

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

Vorgangssequenz

Systemstart

  1. Das Betriebssystem liest die unterstützten Schlüsselworttypen, um sicherzustellen, dass sie Schlüsselwörter in diesem Format enthält.
  2. Das Betriebssystem registriert sich für das Detektorstatusänderungsereignis.
  3. Das Betriebssystem legt die Schlüsselwortmuster fest.
  4. Das Betriebssystem bewaffnet den Detektor.

Beim Empfangen des KS-Ereignisses

  1. Der Fahrer entwärmt den Detektor.
  2. Das Betriebssystem liest den Schlüsselwortdetektorstatus, analysiert die zurückgegebenen Daten und bestimmt, welches Muster erkannt wurde.
  3. Das Betriebssystem rückt den Detektor neu.

Interner Treiber- und Hardwarevorgang

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 zu mehreren Sekunden sein.) Der Erkennungsalgorithmus funktioniert über diesen Puffer auf dem Datenstreaming. Das Design des Treibers und der Hardware ist so, dass beim Bewaffneten keine Interaktion zwischen dem Treiber und der Hardware vorhanden ist und keine Unterbrechungen für die "Anwendung"-Prozessoren ausgeführt werden, bis ein Schlüsselwort erkannt wird. Dadurch kann das System einen niedrigeren Leistungszustand erreichen, wenn keine andere Aktivität vorhanden ist.

Wenn die Hardware ein Schlüsselwort erkennt, generiert er eine Unterbrechung. Beim Warten des Treibers auf den Dienst für die Unterbrechung wird die Hardware weiterhin Audio in den Puffer aufnehmen, um sicherzustellen, dass keine Daten nach dem Verlust des Schlüsselworts verloren gehen, innerhalb von Puffergrenzen.

Schlüsselwortzeitstempel

Nach dem Erkennen eines Schlüsselworts müssen alle Sprachaktivierungslösungen alle gesprochenen Schlüsselworte puffern, einschließlich 250Ms vor dem Start des Schlüsselworts. Der Audiotreiber muss Zeitstempel bereitstellen, die den Start und das Ende des Schlüsselausdrucks im Stream identifizieren.

Um die Schlüsselwortstart-/Endzeitstempel zu unterstützen, muss DSP-Software möglicherweise intern Zeitstempelereignisse basierend auf einer DSP-Uhr intern verwenden. Nachdem ein Schlüsselwort 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 Leistungszählerwert zuordnen. Die Methode der Ausführung ist speziell für das Hardwaredesign. Eine mögliche Lösung ist für den Treiber zum Lesen des aktuellen Leistungsindikatorens, Abfragen des aktuellen DSP-Zeitstempels, lesen Sie den aktuellen Leistungszähler erneut, und schätzen Sie dann eine Korrelation zwischen Leistungsindikatoren und DSP-Zeit. Anschließend kann der Treiber die Schlüsselwort-DSP-Zeitstempel Windows Leistungsindikatoren-Zeitstempel zuordnen.

Schlüsselwortdetektor-OEM-Adapterschnittstelle

Der OEM stellt eine COM-Objektimplementierung bereit, die 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, der die Mustertyp-GUID angibt, um das entsprechende COM-Objekt zu instanziieren, das mit dem Schlüsselwortmustertyp kompatibel ist und Methoden auf der IKeywordDetectorOemAdapter-Schnittstelle des Objekts aufruft.

COM-Threadingmodellanforderungen

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

IKeywordDetectorOemAdapter

Das Schnittstellendesign versucht, die Objektimplementierung zustandslos zu halten. Mit anderen Worten, die Implementierung sollte keinen Zustand erfordern, der zwischen Methodenaufrufen gespeichert werden soll. In der Tat benötigen interne C++-Klassen wahrscheinlich keine Membervariablen, die über diejenigen hinaus erforderlich sind, um ein COM-Objekt im Allgemeinen zu implementieren.

Methoden

Implementieren Sie die folgenden Methoden.

KEYWORDID

Die KEYWORDID-Aufzählung identifiziert den Ausdruckstext/die Funktion eines Schlüsselworts und wird auch in den Windows biometrischen Dienstadaptern verwendet. Weitere Informationen finden Sie unter Ü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 eine bestimmte Sprache eindeutig auswählen.

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

Behandeln von Modelldaten

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

Dynamisches benutzerabhängiges Modell – IStream stellt ein Speichermodell für zufälligen Zugriff bereit. Das Betriebssystem übergibt einen IStream-Schnittstellenzeiger auf viele der Methoden auf der IKeywordDetectorOemAdapter-Schnittstelle. Das Betriebssystem sichert die IStream-Implementierung mit geeignetem 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 dient zum beständigen Speichern von vom Benutzer abhä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 nie ein Schlüsselwort trainiert hat. Das Betriebssystem erstellt einen separaten IStream-Speicher für jeden Benutzer. Mit anderen Worten, ein gegebener IStream speichert Modelldaten für einen und nur einen Benutzer.

Der OEM-DLL-Entwickler entscheidet, wie benutzerunabhängige und benutzerabhängige Daten verwaltet werden. Sie speichert jedoch niemals Benutzerdaten außerhalb des IStreams. Ein möglicher OEM-DLL-Entwurf würde intern zwischen dem Zugriff auf den IStream und den statischen benutzerunabhängigen Daten wechseln, je nach den Parametern der aktuellen Methode. Ein alternatives Design überprüft möglicherweise den IStream am Anfang der einzelnen Methodenaufrufe und fügt die statischen benutzerunabhängigen Daten zum IStream hinzu, sofern nicht bereits vorhanden, sodass der Rest der Methode nur auf den IStream für alle Modelldaten zugreifen kann.

Schulung und Operation Audioverarbeitung

Wie bereits beschrieben, führt der Schulungs-UI-Fluss zu vollständig phonetisch umfangreichen Sätzen, die im Audiodatenstrom verfügbar sind. Jeder Satz wird einzeln an IKeywordDetectorOemAdapter::VerifyUserKeyword übergeben, um zu überprüfen, ob es das erwartete Schlüsselwort enthält und eine akzeptable Qualität hat. 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 Sprachaktivierungsschulungen verarbeitet. In der folgenden Tabelle werden die Unterschiede zwischen der Sprachaktivierungsschulung und der regulären Spracherkennungsverwendung zusammengefasst.

|

Sprachschulung Spracherkennung
Mode Raw Unformatierte Oder Sprachausgabe
Pin Normal KWS
Audioformat 32-Bit-Float (Typ = Audio, Subtype = IEEE_FLOAT, Samplingrate = 16 kHz, Bits = 32) Verwaltet von Betriebssystemaudiostapel
Mic Mikrofon 0 Alle Mikrofone im Array oder Mono

Übersicht über das Schlüsselworterkennungssystem

Dieses Diagramm enthält eine Übersicht über das Schlüsselworterkennungssystem.

keyword recognition system including cortana the speech runtime and the voice activation manager.

Schlüsselworterkennungssequenzdiagramme

In diesen Diagrammen wird das Sprachlaufzeitmodul als "Sprachplattform" angezeigt. Wie bereits erwähnt, wird die Windows-Sprachplattform verwendet, um alle Spracherfahrungen in Windows 10 wie Cortana und Diktieren zu nutzen.

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

keyword recognition sequence showing training ux speech platform and the oem keyword detector during startup.

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

keyword recognition sequence showing training ux speech platform and the oem keyword detector during learn my voice.

In diesem Diagramm wird der Prozess der Armierung für die Schlüsselworterkennung beschrieben.

keyword recognition sequence showing speech platform oem keyword detector and the audio drive detector during arming for keyword detection.

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 der Betriebssystem-Audiopipeline und die Zuverlässigkeit zu verbessern oder neue Szenarien zu unterstützen. Eine neue PnP-Geräteschnittstelleneigenschaft wird definiert, sodass der Treiber einen statischen Ausdruck seiner Puffergrößeseinschränkungen für das Betriebssystem bereitstellt.

Puffergrößen

Ein Treiber funktioniert unter verschiedenen Einschränkungen beim Verschieben von Audiodaten zwischen dem Betriebssystem, dem Treiber und der Hardware. 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 zugeordneten DSP.

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

Der Treiber drückt die Puffergrößeseinschränkungen aus, indem die DEVPKEY_KsAudio_PacketSize_Constraints Geräteeigenschaft auf der KSCATEGORY_AUDIO PnP-Geräteschnittstelle des KS-Filters mit den KS-Streaming-Pins festgelegt wird. 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 wert der DEVPKEY_KsAudio_PacketSize_Constraints-Eigenschaft enthält eine KSAUDIO_PACKETSIZE_CONSTRAINTS Struktur, die die physischen Hardwareeinschränkungen beschreibt (d. h. aufgrund der Mechanik des Übertragens von Daten vom WaveRT-Puffer an die Audiohardware). 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 vor dem Aufrufen von PcRegisterSubdevice fest oder aktiviert die KS-Filterschnittstelle für seine Streaming-Pins.

IMiniportWaveRTInputStream

Ein Treiber implementiert diese Schnittstelle für eine bessere Koordination von Audiodatenflüssen vom Treiber auf das Betriebssystem. Wenn diese Schnittstelle in einem Aufnahmedatenstrom 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 beraten und präzise Datenstromposition zurückzugeben. Weitere Informationen finden Sie unter IMiniportWaveRTOutputStream::SetWritePacket, IMiniportWaveRTOutputStream::GetOutputStreamPresentationPosition und IMiniportWaveRTOutputStream::GetPacketCount.

Leistungsindikator-Zeitstempel

Mehrere Treiberroutinen geben Windows Leistungsindikator-Zeitstempel zurück, die die Zeit widerspiegeln, zu der Beispiele erfasst oder vom Gerät präsentiert werden.

Bei Geräten mit komplexen DSP-Pipelines und Signalverarbeitung kann es schwierig sein, einen genauen Zeitstempel zu berechnen und sollten sorgfältig ausgeführt werden. Die Zeitstempel sollten nicht einfach die Zeit widerspiegeln, zu der Beispiele an oder vom Betriebssystem an den DSP übertragen wurden.

  • Verfolgen Sie im DSP Zeitstempel mit einigen internen DSP-Wanduhren.
  • 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 hin zu ziemlich komplexen oder romanigen (aber präziseren) reichen.
  • Berücksichtigen Sie konstanten Verzögerungen aufgrund von Signalverarbeitungsalgorithmen oder Pipeline- oder Hardwaretransporten, es sei denn, diese Verzögerungen werden andernfalls berücksichtigt.

Serienlesevorgang

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

Es werden zwei Beispielleseszenarien erläutert. Wenn der Miniport einen Pin unterstützt, der eine Pin-Kategorie KSNODETYPE_AUDIO_KEYWORDDETECTOR enthält, 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 keine Daten schnell genug liest, indem IMiniportWaveRTInputStream::GetReadPacket aufgerufen wird.

Zum Bersten von Daten, die vor dem Übergang zu KSSTATE_RUN erfasst wurden, muss der Treiber genaue Zeitstempelinformationen zusammen mit den pufferten Erfassungsdaten aufbewahren. Die Zeitstempel identifizieren den Sampling-Instant der erfassten Beispiele.

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

  2. In 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 (0 für das erste Paket nach dem Übergang von KSSTATE_STOP zu KSSTATE_RUN) zurück, von dem 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 viel Aufnahmedaten innerhalb der Hardware oder des Treibers (außerhalb des WaveRT-Puffers) gepuffert wurden.

    c. Wenn mehr ungelesene pufferte Daten verfügbar sind, ist entweder der Treiber verfügbar: i. Übertragen Sie sofort diese Daten in den verfügbaren Raum des WaveRT-Puffers (z. B. Leerzeichen, die von GetReadPacket zurückgegeben werden), gibt true für MoreData zurück, und legt das Pufferbenachrichtigungsereignis fest, bevor Sie aus dieser Routine zurückkehren. Oder ii. Programmhardware, um das nächste Paket in den verfügbaren Raum des WaveRT-Puffers zu füllen, 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 mithilfe der von GetReadPacket() zurückgegebenen Informationen.

  4. Das Betriebssystem wartet auf das nächste Pufferbenachrichtigungsereignis. Die Wartezeit kann sofort beendet werden, 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 mehr erfasste Daten in den WaveRT-Puffer übertragen und es dem Betriebssystem zur Verfügung stellt, um zu lesen.

  6. Wechseln Sie zu (2). Für KSNODETYPE_AUDIO_KEYWORDDETECTOR Schlüsselwortdetektor-Pins sollten Treiber genügend interne Platzpuffer für mindestens 5000 m Audiodaten zuweisen. Wenn das Betriebssystem keinen Datenstrom auf dem Pin erstellt, bevor der Puffer überläuft, kann der Treiber die interne Pufferaktivität beenden und freie zugeordnete Ressourcen.

Auf Voice aktivieren

Mit "Wake On Voice" (WoV) kann der Benutzer ein Spracherkennungsmodul aus einem Bildschirm aus, einem unteren Leistungszustand, auf einem Bildschirm aktivieren und abfragen, indem er ein bestimmtes Schlüsselwort wie "Hey Cortana" sagt.

Dieses Feature ermöglicht es dem Gerät, immer auf die Stimme des Benutzers zu hören, während sich das Gerät in einem Zustand mit niedriger Leistung befindet, einschließlich, wenn der Bildschirm deaktiviert ist und das Gerät leer ist. Dies geschieht mithilfe eines Hörmodus, der im Vergleich zu der viel höheren Stromnutzung während der normalen Mikrofonaufzeichnung deutlich niedriger ist. Mit der Spracherkennung mit geringer Leistung kann ein Benutzer einfach einen vordefinierten Schlüsselausdruck wie "Hey Cortana" sagen, gefolgt von einem geketteten Sprachausdruck wie "wann ist mein nächster Termin", um die Sprache auf eine freihandfreie Weise aufzurufen. Dies funktioniert unabhängig davon, ob das Gerät mit dem Bildschirm deaktiviert oder leer ist.

Der Audiostapel ist für die Kommunikation der Wake-Daten (Sprecher-ID, Schlüsselwortauslöser, Vertrauensstufe) sowie die Benachrichtigung interessierter Clients verantwortlich, dass das Schlüsselwort erkannt wurde.

Überprüfung auf modernen Standbysystemen

WoV aus einem System-Leerlaufzustand kann auf modernen Standby-Systemen mithilfe des Modern Standby Wake on Voice Basic Test on AC-Power Source und dem Modern Standby Wake on Voice Basic Test auf DC-Power Source in der HLK überprüft werden. Diese Tests überprüfen, ob das System über einen Hardware-Schlüsselwort-Spotter (HW-KWS) verfügt, in der Lage ist, den Deepest Runtime Idle Platform State (DRIPS) einzugeben und kann von Modern Standby on Voice-Befehl mit systembezogener Latenz von weniger als oder gleich einer Sekunde gestartet werden.