Mehrere Sprachassistenten

Die Plattform "Multiple Voice Assistant" bietet Unterstützung für zusätzliche Sprachassistenten in Windows. Dadurch können andere Assistenten auf Windows-Geräten wie PCs und Wearables wie HoloLens verfügbar sein. Mehrere Sprachassistenten können auf demselben Gerät mit einer Reihe unterstützter Schlüsselwortmuster aktiv sein.

Informationen zur Implementierung von Windows Cortana finden Sie unter "Sprachaktivierung".

Sprachaktivierung

Die Sprachaktivierung ist ein Feature, mit dem Benutzer ein Spracherkennungsmodul aus verschiedenen Geräteleistungszuständen aufrufen können, indem sie einen bestimmten Ausdruck sagen.

Die Implementierung der VoIP-Aktivierung 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 zu erhalten.

Mit der Sprachaktivierung können Benutzer die Sprachassistenten schnell außerhalb ihres aktiven Kontexts (d. h. auf dem Bildschirm) mithilfe ihrer Stimme einbinden. Benutzer möchten häufig sofort auf eine Erfahrung zugreifen können, ohne physisch mit einem Gerät interagieren zu müssen. Für einen Xbox-Nutzer kann dies daran liegen, dass er möglicherweise keine Lust hat, einen Controller zu suchen und zu verbinden. Für PC-Benutzer möchten sie möglicherweise schnell auf eine Erfahrung zugreifen, ohne mehrere Maus-, Touch- und/oder Tastaturaktionen ausführen zu müssen, wie bei einem Computer in der Küche.

Die Sprachaktivierung wird durch einen Schlüsselwort-Spotter (KWS) unterstützt, der reagiert, wenn der Schlüsselbegriff erkannt wird. Schlüsselbegriffe können Schlüsselwörter wie "Hey Contoso" enthalten. Die Schlüsselworterkennung beschreibt die Erkennung des Schlüsselworts entweder durch Hardware oder Software.

Schlüsselausdrücke können für sich stehend ("Hey Contoso") als eigenständiger Befehl oder gefolgt von einer Sprachaktion, die einen verketteten Befehl bildet ("Hey Contoso, wo ist meine nächste Besprechung?")

Microsoft stellt einen standardmäßigen Betriebssystem-Schlüsselwort-Spotter (Software-Schlüsselwort-Spotter) bereit, um Sprachassistenten in Fällen bereitzustellen, in denen die Erkennung von Hardwareschlüsselworten nicht verfügbar ist. Obwohl dies derzeit für Cortana verfügbar ist, ist möglicherweise eine zusätzliche Microsoft-Konfiguration erforderlich, um andere Sprachassistenten zu integrieren, um die Schlüsselworterkennung in zwei Phasen durchzuführen. Für weitere Informationen wenden Sie sich an AskMVA@Microsoft.com.

Wenn KWS das Gerät aus einem energiesparenden Zustand wecken soll, wird die Lösung als Wake-on-Voice (WoV) bezeichnet. Weitere Informationen finden Sie weiter unten in diesem Artikel unter Wake on Voice .

Glossar der Begriffe

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

Integrieren eines Hardware-Schlüsselwort-Spotters

Zur Implementierung eines Hardwareschlüsselwort-Spotters (HW KWS) müssen SoC-Anbieter die folgenden Aufgaben ausführen.

• Erstellen Sie einen benutzerdefinierten Schlüsselwortdetektor basierend auf dem weiter unten in diesem Thema beschriebenen SYSVAD-Beispiel. Sie implementieren diese Methoden in einer COM-DLL, die in der IEvent-Detektor-OEM-Adapterschnittstelle beschrieben wird.
• Implementieren Sie WAVE RT-Verbesserungen, die in DEN 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 der Empfehlung für Audiogeräte. Dieses Thema enthält Anleitungen und Empfehlungen für das Design und die Entwicklung von Audioeingabegeräten, die für die Verwendung mit der Sprachplattform von Microsoft vorgesehen sind.
• Sowohl mehrstufige als auch verkettete Befehle werden unterstützt.
• Erfüllen Sie die Anforderungen an das Gebietsschema von Sprachassistenten
• 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.
• Das APO muss das folgende Format ausgeben:
  • 16 kHz, Mono, FLOAT.
• Entwerfen Sie optional alle benutzerdefinierten APOs, um den Audioaufnahmeprozess zu verbessern. Weitere Informationen finden Sie unter Windows Audio Processing Objects.

Hardware-ausgelagerter Schlüsselwort-Erkenner (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

AEC kann vom DSP zum Zeitpunkt der Aufnahme des Burst-Audios durchgeführt werden, oder es kann zu einem späteren Zeitpunkt über eine Software-APO erfolgen. Um eine Software AEC mit KWS-Burstdaten durchzuführen, ist es notwendig, die entsprechenden Loopback-Audiodaten ab dem Zeitpunkt der Aufnahme der Burstdaten zu haben. Dazu wurde ein benutzerdefiniertes Audioformat für die Burst-Ausgabe erstellt, das die Loopback-Audio in die Burst-Audiodaten einfügt.

Ab Windows Version 20H1 ist das Microsoft AEC APO dieses überlappenden Formats bekannt und kann es zum Ausführen der AEC verwenden. Weitere Informationen finden Sie unter KSPROPERTY_INTERLEAVEDAUDIO_FORMATINFORMATION.

Validierung

Überprüfen Sie die HW-Unterstützung für KSPROPSETID_SoundDetector2 Eigenschaften mit Voice Activation Manager 2-Tests.

Beispielcodeübersicht

Es gibt Beispielcode für einen Audiotreiber, der die Sprachaktivierung auf GitHub als Teil des virtuellen SYSVAD-Audioadapterbeispiels implementiert. Es wird empfohlen, diesen Code als Ausgangspunkt zu verwenden.

Weitere Informationen zum SYSVAD-Beispielaudiotreiber finden Sie unter Beispielaudiotreiber.

Informationen zum Schlüsselworterkennungssystem

Unterstützung für Sprachaktivierungs-Audiostack

Die externen Schnittstellen des Audiostapels für die Sprachaktivierung dienen als Kommunikationskanal zwischen der Sprachplattform und den Audiotreibern. Die externen Schnittstellen sind in drei Teile unterteilt.

• Ereignisdetektor-Device Driver Interface (DDI) Die Ereignisdetektorgerätetreiberschnittstelle ist für die Konfiguration und Armierung des HW Keyword Spotter (KWS) verantwortlich. Es wird auch vom Treiber verwendet, um das System über ein Erkennungsereignis zu benachrichtigen.
• IEvent-Detektor OEM Adapter DLL. Diese DLL implementiert eine COM-Schnittstelle, um die treiberspezifischen undurchsichtigen Daten zur Verwendung durch das Betriebssystem anzupassen, um die Schlüsselworterkennung zu unterstützen.
• WaveRT-Verbesserungen. Mit den Verbesserungen kann der Audiotreiber die gepufferten Audiodaten aus der Schlagworterkennung effizient streamen.

Audioendpunkteigenschaften

Das Erstellen von Audioendpunktdiagrammen erfolgt normal. Das Diagramm ist darauf vorbereitet, schneller als die Echtzeiterfassung zu verarbeiten. Zeitstempel bei erfassten Puffern bleiben unverändert. Insbesondere spiegeln die Zeitstempel korrekt Daten wider, die in der Vergangenheit erfasst und gepuffert wurden, und ist jetzt platzend.

Theorie des Bluetooth-Bypassing beim Audiostreaming

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 zum Konfigurieren, Aktivieren und Signalisieren eines Erkennungsereignisses. Der Filter enthält auch eine zusätzliche Pin-Factory, die als Schlüsselwort-Spotter (KWS)-Pin identifiziert wird. Dieser Pin wird verwendet, um Audio aus dem Schlüsselwort-Spotter zu streamen.

Die Eigenschaft lautet: KSPROPSETID_SoundDetector2

Alle KSPROPSETID_SoundDetector2 Eigenschaften werden mit einer KSSOUNDDETECTORPROPERTY-Datenstruktur aufgerufen. Diese Datenstruktur enthält eine KSPROPERTY und die Ereignis-ID für das Schlüsselwort, das bewaffnet, zurückgesetzt, erkannt usw. werden soll.

• 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 unterstützter 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üsselwortdetektor verwendet wird. 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 sein.)
• Übereinstimmungsergebnis – KSPROPERTY_SOUNDDETECTOR_RESET wird verwendet, um den Sounddetektor beim Start zurückzusetzen.

Zur Schlüsselworterkennungszeit wird eine PNP-Benachrichtigung gesendet, die KSNOTIFICATIONID_SoundDetector enthält. HINWEIS: Dies ist kein KSEvent, sondern ein PNP-Ereignis, das mit einer Nutzlast über IoReportTargetDeviceChangeAsynchronous gesendet wird.

KSNOTIFICATIONID_SoundDetector ist wie hier gezeigt in ksmedia.h definiert.

// The payload of this notification is a SOUNDDETECTOR_PATTERNHEADER
#define STATIC_KSNOTIFICATIONID_SoundDetector\
    0x6389d844, 0xbb32, 0x4c4c, 0xa8, 0x2, 0xf4, 0xb4, 0xb7, 0x7a, 0xfe, 0xad
DEFINE_GUIDSTRUCT("6389D844-BB32-4C4C-A802-F4B4B77AFEAD", KSNOTIFICATIONID_SoundDetector);
#define KSNOTIFICATIONID_SoundDetector DEFINE_GUIDNAMED(KSNOTIFICATIONID_SoundDetector)

Abfolge des Vorgangs

Systemstart

1. Das Betriebssystem sendet eine KSPROPERTY_SOUNDDETECTOR_RESET, um jeden vorherigen Betriebszustand der Detektoren zu löschen, alle Detektoren auf deaktiviert zurückzusetzen und vorherige Muster zu entfernen.
2. Das Betriebssystem fragt KSPROPERTY_SOUNDDETECTOR_PATTERNS ab, um die CLSID für den Ereignisdetektor-OEM-Adapter abzurufen.
3. Das Betriebssystem verwendet den Ereignisdetektor-OEM-Adapter, um die Liste der unterstützten Schlüsselwörter und Sprachen abzurufen.
4. Das Betriebssystem registriert sich für benutzerdefinierte PNP-Benachrichtigungen, die vom Treiber gesendet werden
5. Das Betriebssystem legt das erforderliche Schlüsselwortmuster fest.
6. Das Betriebssystem bewaffnet den Detektor(n)

Interner Treiber- und Hardwarebetrieb

Während der Detektor aktiviert ist, kann die Hardware kontinuierlich Audiodaten in einem kleinen FIFO-Puffer erfassen und speichern. (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. Der Entwurf des Treibers und der Hardware ist so, dass während sie aktiv sind, keine Interaktion zwischen Treiber und Hardware besteht und keine Unterbrechungen für die Anwendungsprozessoren 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, wird ein Interrupt generiert. Während sie warten, bis der Treiber den Interrupt bedient, erfasst die Hardware weiterhin Audio im Puffer, wobei sichergestellt wird, dass keine Daten nach dem Verlust des Schlüsselworts innerhalb von Puffergrenzwerten verloren gehen.

Stichwort-Zeitstempel

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

Um die Schlüsselwort-Start-/Endzeitstempel zu unterstützen, muss DSP-Software möglicherweise Ereignisse intern mit Zeitstempeln versehen, basierend auf einer DSP-Uhr. Sobald 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 den DSP-Zeitstempel einem Windows-Leistungsindikatorwert zuordnen. Die Methode hierfür ist spezifisch für das Hardwaredesign. Eine mögliche Lösung ist, 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. Angesichts der Korrelation kann der Treiber die DSP-Zeitstempel der Schlüsselwörter den Zeitstempeln des Windows-Leistungsanzeigers zuordnen.

IEvent-Detektor-OEM-Adapterschnittstelle

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, indem die Mustertyp-GUID übergeben wird, um das entsprechende COM-Objekt zu instanziieren, das mit dem Schlüsselwortmustertyp kompatibel ist, und ruft Methoden auf der IEventDetectorOemAdapter-Schnittstelle des Objekts auf.

COM-Threading-Modell-Anforderungen

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

IEventDetectorOemAdapter

Der Schnittstellenentwurf versucht, die Objektimplementierung zustandslos zu halten. Mit anderen Worten, die Implementierung sollte keinen Zustand zwischen Methodenaufrufen speichern. In der Tat benötigen interne C++-Klassen wahrscheinlich keine Membervariablen, die über diejenigen hinausgehen, die zum Implementieren eines COM-Objekts im Allgemeinen erforderlich sind.

Methodik

Implementieren Sie die folgenden Methoden.

• IEventDetectorOemAdapter::BuildArmingPatternData
• IEventDetectorOemAdapter::ComputeAndAddUserModelData
• IEventDetectorOemAdapter::GetCapabilities
• IEventDetectorOemAdapter::GetCapabilitiesForLanguage
• IEventDetectorOemAdapter::ParseDetectionResultData
• IEventDetectorOemAdapter::ReportOSDetectionResult
• IEventDetectorOemAdapter::VerifyUserEventData

WAVERT-Verbesserungen

Miniport-Schnittstellen werden definiert, die von WaveRT-Miniporttreibern implementiert werden sollen. Diese Schnittstellen bieten Methoden, um den Audiotreiber zu vereinfachen, die Leistung und Zuverlässigkeit der Betriebssystem-Audiopipeline zu verbessern oder neue Szenarien zu unterstützen. Eine PnP-Geräteschnittstelleneigenschaft wird definiert, sodass der Treiber einen statischen Ausdruck seiner Puffergrößeneinschränkungen für das Betriebssystem bereitstellt.

Puffergrößen

Ein Treiber arbeitet 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 200 ms unterstützen.

Der Treiber drückt die Einschränkungen der Puffergröße aus, indem er die DEVPKEY_KsAudio_PacketSize_Constraints2-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 ein Handle für den Treiber zu öffnen und den Treiber aufrufen zu müssen.

DEVPKEY_KsAudio_PacketSize_Constraints2

Der wert der DEVPKEY_KsAudio_PacketSize_Constraints2-Eigenschaft enthält eine KSAUDIO_PACKETSIZE_CONSTRAINTS2 Struktur, die die physischen Hardwareeinschränkungen beschreibt (d. h. aufgrund der Mechanik der Übertragung von Daten aus dem 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 bestimmte Signalverarbeitungsmodi spezifisch sind. Der Treiber legt diese Eigenschaft fest, bevor PcRegisterSubdevice aufgerufen wird oder die KS-Filterschnittstelle für seine Streaming-Pins aktiviert wird.

IMiniportWaveRTInputStream

Ein Treiber implementiert diese Schnittstelle zur besseren Koordination des Audiodatenflusses vom Treiber zum 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 über den Schreibfortschritt vom Betriebssystem informiert zu werden und die präzise Streamposition zurückzugeben. Weitere Informationen finden Sie unter "IMiniportWaveRTOutputStream::SetWritePacket", "IMiniportWaveRTOutputStream::GetOutputStreamPresentationPosition " und "IMiniportWaveRTOutputStream::GetPacketCount".

Leistungszähler-Zeitstempel

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

Bei Geräten mit komplexen DSP-Pipelines und Signalverarbeitung kann die Berechnung eines genauen Zeitstempels eine Herausforderung darstellen und sorgfältig durchgeführt werden. Die Zeitstempel sollten nicht einfach die Zeit widerspiegeln, zu der Proben in das Betriebssystem oder vom DSP übertragen wurden.

• Verfolgen Sie im DSP die Sample-Zeitstempel mithilfe einer internen DSP-Wanduhr.
• Berechnen Sie zwischen 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 neuartigen (aber präziseren) Reichen.
• Berücksichtigen Sie konstante Verzögerungen aufgrund von Signalverarbeitungsalgorithmen, Pipeline- oder Hardwaretransporten, es sei denn, diese Verzögerungen werden anderweitig berücksichtigt.

Burst-Lesevorgang

In diesem Abschnitt wird die Interaktion zwischen Betriebssystem und Treiber für Burst-Lesevorgänge beschrieben. Platzlesevorgä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 Beispiel-Lesevorgänge im Burst-Modus erörtert. Wenn der Miniport in einem Szenario einen Pin unterstützt, der eine Pinkategorie 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 intern Daten außerhalb des WaveRT-Puffers puffern, wenn das Betriebssystem daten nicht schnell genug liest, indem IMiniportWaveRTInputStream::GetReadPacket aufgerufen wird.

Um Daten freizugeben, die vor dem Übergang in den Zustand KSSTATE_RUN erfasst wurden, muss der Treiber genaue Zeitstempelinformationen der Probe zusammen mit den gepufferten Erfassungsdaten aufbewahren. Die Zeitstempel identifizieren den Entnahmezeitpunkt der erfassten Proben.

1. Nachdem der Datenstrom 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 der das Betriebssystem die Paketposition innerhalb des WaveRT-Puffers sowie die Paketposition relativ zum Start des Datenstroms ableiten kann.

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

   Abschnitt c. Wenn mehr ungelesene gepufferte Daten verfügbar sind, hat der Treiber zwei Möglichkeiten: i. Diese Daten werden sofort in den verfügbaren Raum des WaveRT-Puffers übertragen (d. h. speicherplatz, der vom von GetReadPacket zurückgegebene Paket nicht verwendet wird), gibt "true" für MoreData zurück und legt das Pufferbenachrichtigungsereignis fest, bevor es von dieser Routine zurückgegeben wird. Oder ii. Programmiert Hardware, um das nächste Paket in den verfügbaren Speicherplatz des WaveRT-Puffers zu übertragen, gibt 'false' für MoreData zurück und setzt das Puffereignis später, wenn die Übertragung abgeschlossen ist.

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

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 es mehr erfasste Daten in den WaveRT-Puffer überträgt und es dem Betriebssystem zum Lesen zur Verfügung stellt.

6. Gehe zu (2).

Für KSNODETYPE_AUDIO_KEYWORDDETECTOR Schlüsselwortdetektor-Pins sollten Treiber genügend interne Burstpuffer für mindestens 5000 ms Audiodaten zuordnen. Wenn das Betriebssystem keinen Datenstrom auf dem Pin erstellt, bevor der Pufferüberlauf erfolgt, kann der Treiber die interne Pufferaktivität beenden und zugeordnete Ressourcen freigeben.

Aufwecken durch Stimme

Wake-on-Voice (WoV) ermöglicht dem Benutzer das Aktivieren und Abfragen eines Spracherkennungsmoduls von einem Energiesparmodus bis zu einem vollständigen Leistungszustand, auf dem der Bildschirm eingeschaltet ist, indem ein bestimmtes Schlüsselwort wie "Hey Contoso" angegeben wird.

Mit diesem Feature kann das Gerät immer auf die Stimme des Benutzers lauschen, während sich das Gerät im Leerlauf befindet und der Bildschirm ausgeschaltet ist. Dies liegt daran, dass der Hörmodus im Vergleich zur normalen Mikrofonaufnahme viel weniger Energie verwendet. WoV ermöglicht verkettete Sprachausdrücke wie "Hey Contoso, wann ist mein nächster Termin", um eine Antwort von einem Sprachassistenten freihändig zu erhalten.

Der Audiostapel ist für die Kommunikation der Wake-Daten (Lautsprecher-ID, Schlüsselworttrigger, Kontextinformationen auf Konfidenzniveau) sowie für die Benachrichtigung interessierter Clients verantwortlich, dass das Schlüsselwort erkannt wurde.

Validierung bei modernen Standby-Systemen

WoV aus einem System-Leerlaufzustand kann auf modernen Standby-Systemen mit dem Modern Standby Wake on Voice Basic Test bei Stromversorgung mit Wechselstrom und dem Modern Standby Wake on Voice Basic Test bei Stromversorgung mit Gleichstrom im HLK überprüft werden. Diese Tests überprüfen, ob das System über einen Hardwareschlüsselwort-Spotter (HW-KWS) verfügt, in der Lage ist, in den Deepest Runtime Idle Platform State (DRIPS) einzutreten und auf Sprachbefehl aus dem Modern Standby-Modus mit einer Systemaufwachlatenz von weniger als oder gleich einer Sekunde zu reaktivieren.

ACX und MVA

Audio Class eXtension (ACX) definiert eine WDF-Klassenerweiterung (Windows Driver Framework) für die Audiodomäne. Weitere Informationen zu ACX finden Sie unter ACX-Audioklassenerweiterungen (Übersicht ) und Zusammenfassung der ACX-Objekte. In diesem Abschnitt wird beschrieben, wie MVA mithilfe von ACX implementiert wird.

ACX verwendet dieselbe KS-Infrastruktur für den Schlüsselwort-Spotter und fügt eine Abstraktionsebene hinzu, um die Treiberimplementierung zu vereinfachen. Bei ACX wird dieselbe OEM-DLL wie oben beschrieben verwendet und bleibt unverändert. Sowohl ACX als auch Portcls erfordern die IEventDetectorOEMAdapter-Schnittstelle, und es gibt keinen Unterschied bei der Implementierung zwischen den beiden für den OEM-Adapter.

Die AcxKeywordSpotterCreate-Funktion wird verwendet, um ein ACX-Schlüsselwort-Spotter-opaque-Objekt (ACXKEYWORDSPOTTER) zu erstellen, das einem übergeordneten Schaltkreisgerätobjekt zugeordnet wird.

Das ACXKEYWORDSPOTTER-Objekt wird verwendet, um alle KSPROPERTY_SOUNDDETECTOR Aufrufe zu ersetzen und die KWS-Implementierung zu vereinfachen. Es wird beim Hinzufügen eines KWS-Elements und eines KWS-Pins zum ACX-Schaltkreis verwendet. Die zugehörigen Callbacks kümmern sich um das Abrufen von Mustern, die Aktivierung, die Deaktivierung und das Zurücksetzen. Es verwendet eine initialisierte ACX_KEYWORDSPOTTER_CONFIG Struktur , die die Konfiguration des Schlüsselwort-Spotters beschreibt.

Die ACX_KEYWORDSPOTTER_CONFIG-Struktur verwendet eine ACX_KEYWORDSPOTTER_CALLBACKS Struktur , die die folgenden Rückrufe definiert.

EvtAcxKeywordSpotterRetrieveArm - Die ACX_KEYWORDSPOTTER_RETRIEVE_ARM Callback-Funktion.

EvtAcxKeywordSpotterAssignArm - Der ACX_KEYWORDSPOTTER_ASSIGN_ARM-Callback.

EvtAcxKeywordSpotterAssignPatterns - Der ACX_KEYWORDSPOTTER_ASSIGN_PATTERNS Callback-Funktion.

EvtAcxKeywordSpotterAssignReset - Die ACX_KEYWORDSPOTTER_ASSIGN_RESET Callback-Funktion.

ACX PNP-Ereignis

Das ACX PNP-Ereignis ersetzt KSNOTIFICATIONID_SoundDetector und vereinfacht das Erkennungsbenachrichtigungsereignis. Die ACX_PNPEVENT_CONFIG_INIT-Funktion initialisiert eine ACX_PNPEVENT_CONFIG Struktur. Mit dieser Funktion werden keine Eingaben verwendet.

ACX KWS-Beispielcode

Der ACX KWS-Beispielcode zeigt die Initialisierung der Rückrufe, Schlüsselwortelemente und die Erstellung des Schlüsselwort-Spotters.

{
    NTSTATUS                        status;
    WDF_OBJECT_ATTRIBUTES           attributes;
    ACX_KEYWORDSPOTTER_CALLBACKS    keywordSpotterCallbacks;
    ACX_KEYWORDSPOTTER_CONFIG       keywordSpotterCfg;
    PCODEC_KEYWORDSPOTTER_CONTEXT   keywordSpotterCtx;
    ACX_PNPEVENT_CONFIG             keywordEventCfg;
    ACXPNPEVENT                     keywordEvent;

    PAGED_CODE();

    ACX_KEYWORDSPOTTER_CALLBACKS_INIT(&keywordSpotterCallbacks);
    keywordSpotterCallbacks.EvtAcxKeywordSpotterRetrieveArm = CodecC_EvtAcxKeywordSpotterRetrieveArm;
    keywordSpotterCallbacks.EvtAcxKeywordSpotterAssignArm = CodecC_EvtAcxKeywordSpotterAssignArm;
    keywordSpotterCallbacks.EvtAcxKeywordSpotterAssignPatterns = CodecC_EvtAcxKeywordSpotterAssignPatterns;
    keywordSpotterCallbacks.EvtAcxKeywordSpotterAssignReset = CodecC_EvtAcxKeywordSpotterAssignReset;
    
    ACX_KEYWORDSPOTTER_CONFIG_INIT(&keywordSpotterCfg);
    keywordSpotterCfg.Pattern = &CONTOSO_KEYWORDCONFIGURATION_IDENTIFIER2;
    keywordSpotterCfg.Callbacks = &keywordSpotterCallbacks;
    
    WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE(&attributes, CODEC_KEYWORDSPOTTER_CONTEXT);
    attributes.ParentObject = Circuit;

Als Nächstes wird die AcxKeywordSpotterCreate-Funktion verwendet, um das ACX-Schlüsselwort-Spotter-Objekt zu erstellen und es einem vorhandenen Schaltkreis zuzuordnen.

    status = AcxKeywordSpotterCreate(Circuit, &attributes, &keywordSpotterCfg, Element);
    if (!NT_SUCCESS(status))
    {
        ASSERT(FALSE);
        goto exit;
    }

Anschließend wird der Kontext des Schlüsselwort-Erkenners bestimmt und zum Erstellen des KeywordDetectors im NonPagedPoolNx-Speicher verwendet.

    
    keywordSpotterCtx = GetCodecKeywordSpotterContext(*Element);
    ASSERT(keywordSpotterCtx);
    
    keywordSpotterCtx->KeywordDetector = (PVOID) new(NonPagedPoolNx, DRIVER_TAG) CKeywordDetector();
    if (keywordSpotterCtx->KeywordDetector == NULL)
    {
        status = STATUS_INSUFFICIENT_RESOURCES;
        ASSERT(FALSE);
        goto exit;
    }

In diesem Beispielcode wird die CKeywordDetector-Klasse, die dem Kontext hinzugefügt wird, nur als Beispielimplementierung bereitgestellt, die das Erkennen von Schlüsselwörtern innerhalb des Beispieltreibers simuliert. Die CKeywordDetector-Klasse ist nicht Teil des ACX-Frameworks oder eines erforderlichen Teils der Implementierung von MVA auf ACX, bietet aber möglicherweise einen guten Ausgangspunkt für die Entwicklung eines tatsächlichen Schlüsselwort-Spotters.

Schließlich wird das ACX PnP-Ereignis konfiguriert und erstellt.

   
    ACX_PNPEVENT_CONFIG_INIT(&keywordEventCfg);
    
    WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE(&attributes, CODEC_PNPEVENT_CONTEXT);
    attributes.ParentObject = *Element;
    status = AcxPnpEventCreate(Device, *Element, &attributes, &keywordEventCfg, &keywordEvent);
    if (!NT_SUCCESS(status))
    {
        ASSERT(FALSE);
        goto exit;
    }

    keywordSpotterCtx->Event = keywordEvent;

    //
    // Done. 
    //
    status = STATUS_SUCCESS;

}

Schaltkreise mit komplexem Pinverhalten einschließlich KWS

Bei Schaltkreisen mit komplexem Pinverhalten wie Schaltkreisen mit Hostmodul und/oder KWS sollte der Treiber ACX deaktivieren, um die Stream-Bridge-Handhabung zu verhindern und stattdessen eine Stream-Brücke ohne Inmode zu erstellen. Durch diesen Ansatz wird verhindert, dass ACX Datenströme automatisch Stream-Brücken zuordnet.

Siehe auch

Sprachaktivierung