Freigeben über

Assistent für mehrere Sprachbefehle

  • Artikel

Die Plattform „Assistent für mehrere Sprachbefehle“ 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. Mithilfe einer Reihe unterstützter Schlüsselwortmuster können mehrere Sprachassistenten auf demselben Gerät aktiv sein.

Hinweis

Der Assistent für mehrere Sprachbefehle wird ab Windows 10, Version 1903, unterstützt.

Informationen zur Implementierung von Windows Cortana finden Sie unter Sprachaktivierung.

Voice-Aktivierung

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 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.

Durch die Sprachaktivierung können Benutzer mithilfe ihrer Stimme schnell auf das Sprachassistenten-Erlebnis außerhalb ihres aktiven Kontexts (d. h. dessen, was gerade auf dem Bildschirm angezeigt wird) zugreifen. Benutzer möchten oft sofort auf ein Erlebnis zugreifen können, ohne physisch mit einem Gerät interagieren oder es berühren zu müssen. Für einen Xbox-Benutzer kann dies daran liegen, dass er keinen Controller finden und anschließen möchte. PC-Benutzer möchten möglicherweise schnell auf ein Erlebnis zugreifen, ohne mehrere Maus-, Berührungs- und/oder Tastaturaktionen ausführen zu müssen, wie es bei einem Computer in der Küche der Fall ist.

Die Sprachaktivierung erfolgt durch eine Schlüsselworterkennung (Keyword Spotter, KWS) die reagiert, wenn die Schlüsselphrase 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üsselsätze können einzeln („Hey Contoso“) als mehrstufiger Befehl ausgesprochen werden oder eine nachfolgende Sprachaktion beinhalten, die einen verketteten Befehl bildet („Hey Contoso, wo findet meine nächste Besprechung statt?“).

Microsoft stellt eine standardmäßige Schlüsselworterkennung des Betriebssystems (Software-Schlüsselworterkennung) bereit, um die Erfahrung eines Sprachassistenten in Fällen bereitzustellen, in denen die Hardware-Schlüsselworterkennung 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 für die zweistufige Schlüsselworterkennung zu integrieren. Wenden Sie sich an AskMVA@Microsoft.com, um weitere Informationen zu erhalten.

Wenn die Schlüsselworterkennung das Gerät aus einem Energiesparzustand reaktivieren 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.

Begriff Beispiel/Definition
Mehrstufiger Befehl Beispiel: Hey Contoso <Pause, warten auf Benutzeroberfläche des Assistenten> Wie ist das Wetter? Dies wird manchmal als „Two-Shot-Befehl“ oder „Nur Schlüsselwort“ bezeichnet.
Verketteter Befehl Beispiel: Hey Contoso, wie ist das Wetter? Dies wird manchmal als „One-Shot-Befehl“ bezeichnet.
Voice-Aktivierung Beispiel: „Hey Contoso“ Das Szenario, in dem ein Schlüsselwort in einem vordefinierten Aktivierungsschlüsselsatz erkannt wird.
Wake-on-Voice (WoV) Technologie, die die Sprachaktivierung von einem Bildschirm mit ausgeschaltetem Bildschirm und einem niedrigeren Energiezustand bis hin zu einem Bildschirm mit voller Energie 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 Contoso“ 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-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 Ereignisdetektor Eine Benutzermoduskomponente, die als Vermittler zwischen dem Windows-Sprachassistentenstapel und dem Treiber fungiert.
Modell Die vom KWS-Algorithmus verwendete Akustikmodelldatendatei. Die Datendatei ist statisch. Modelle werden lokalisiert, eine pro Gebietsschema.
MVA Multiple Voice Agent – HWKWS DDI, die mehrere Agents unterstützt.
SVA Single Voice Agent – vorherige HWKWS DDI, die nur einen einzelnen Agent (Cortana) unterstützt.

Integrieren einer Hardware-Schlüsselworterkennung

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

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

AEC kann vom DSP zum Zeitpunkt der Aufnahme des Burst-Audios oder zu einem späteren Zeitpunkt über einen Software-APO durchgeführt werden. Um eine Software-AEC mit KWS-Burst-Daten durchzuführen, ist es erforderlich, über das entsprechende Loopback-Audio zum Zeitpunkt der Erfassung der Burst-Daten zu verfügen. Zu diesem Zweck wurde ein benutzerdefiniertes Audioformat für die Burst-Ausgabe erstellt, das das Loopback-Audio in die Burst-Audiodaten einfügt.

Ab Windows Version 20H1 kennt das Microsoft AEC APO dieses verschachtelte Format und kann es zur Durchführung des AEC verwenden. Weitere Informationen finden Sie unter KSPROPERTY_INTERLEAVEDAUDIO_FORMATINFORMATION.

Überprüfen

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

Ü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.

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 Ereignisdetektor Die Gerätetreiberschnittstelle für den Ereignisdetektor 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 IEvent-Detektor. 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-Verbesserungen. 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.

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

Zum Zeitpunkt der Schlüsselworterkennung wird eine PNP-Benachrichtigung mit KSNOTIFICATIONID_SoundDetector gesendet. 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 der Vorgänge

Systemstart

  1. Das Betriebssystem sendet ein KSPROPERTY_SOUNDDETECTOR_RESET, um alle vorherigen Detektorzustände zu löschen, alle Detektoren auf „deaktiviert“ zurückzusetzen und zuvor eingestellte Muster zu löschen.
  2. Das Betriebssystem fragt KSPROPERTY_SOUNDDETECTOR_PATTERNS ab, um die clsid für den OEM-Adapter des Ereignisdetektors abzurufen.
  3. Das Betriebssystem verwendet den OEM-Adapter des Ereignisdetektors, 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 die erforderlichen Schlüsselwortmuster fest.
  6. Das Betriebssystem aktiviert den Detektor.

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 1,6 Sekunden 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 des IEvent-Detektors

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 IEventDetectorOemAdapter-Schnittstelle des Objekts auf.

Anforderungen an das COM-Threading-Modell

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

IEventDetectorOemAdapter

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.

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 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_Constraints2 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_Constraints2

Der Wert der DEVPKEY_KsAudio_PacketSize_Constraints2-Eigenschaft enthält eine KSAUDIO_PACKETSIZE_CONSTRAINTS2-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, eine Spracherkennungs-Engine zu aktivieren und von einem Energiesparzustand in einen Vollenergiezustand bei eingeschaltetem Bildschirm zu versetzen, indem er ein bestimmtes Schlüsselwort sagt, z. B. „Hey Contoso“.

Mit dieser Funktion kann das Gerät immer auf die Stimme des Benutzers hören, während das Gerät inaktiv ist und der Bildschirm ausgeschaltet ist. Dies ist auf den Hörmodus zurückzuführen, der im Vergleich zur normalen Mikrofonaufnahme viel weniger Strom verbraucht. WoV ermöglicht verkettete Sprachphrasen wie „Hey Contoso, wann ist meine nächste Besprechung“, um eine Antwort eines Sprachassistenten freihändig auszulösen.

Der Audiostapel ist für die Übermittlung der Aktivierungsdaten (Sprecher-ID, Schlüsselwort-Trigger, Kontextinformationen zum 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.

ACX und MVA

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

ACX verwendet dieselbe KS-Infrastruktur für die Schlüsselworterkennung und fügt eine Abstraktionsebene hinzu, um die Treiberimplementierung zu vereinfachen. Bei ACX wird dieselbe OEM-DLL wie oben beschrieben verwendet, die unverändert bleibt. 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 nicht transparentes Objekt der ACX-Schlüsselworterkennung (ACXKEYWORDSPOTTER) zu erstellen, das einem übergeordneten Verbindungsgeräteobjekt 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 zur ACX-Verbindung verwendet. Die zugehörigen Rückrufe kümmern sich um das Abrufen von Mustern, Aktivierung, Deaktivierung und Zurücksetzen. Es verwendet eine initialisierte ACX_KEYWORDSPOTTER_CONFIG-Struktur, die die Konfiguration der Schlüsselworterkennung beschreibt.

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

EvtAcxKeywordSpotterRetrieveArm – Der ACX_KEYWORDSPOTTER_RETRIEVE_ARM-Rückruf.

EvtAcxKeywordSpotterAssignArm – Der ACX_KEYWORDSPOTTER_ASSIGN_ARM-Rückruf.

EvtAcxKeywordSpotterAssignPatterns – Der ACX_KEYWORDSPOTTER_ASSIGN_PATTERNS-Rückruf.

EvtAcxKeywordSpotterAssignReset – Der ACX_KEYWORDSPOTTER_ASSIGN_RESET-Rückruf.

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 der Schlüsselworterkennung.

{
    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üsselworterkennungsobjekt zu erstellen und es einer vorhandenen Verbindung zuzuordnen.

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

Anschließend wird der Schlüsselworterkennungskontext ermittelt und zum Erstellen des KeywordDetector 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 die Schlüsselworterkennung innerhalb des Beispieltreibers simuliert. Die CKeywordDetector-Klasse ist nicht Teil des ACX-Frameworks oder erforderlicher Teil der Implementierung von MVA auf ACX, kann aber einen guten Ausgangspunkt für die Entwicklung einer tatsächlichen Schlüsselworterkennung bieten.

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;

}

Verbindungen mit komplexem Pin-Verhalten einschließlich KWS

Bei Verbindungen mit komplexem Pin-Verhalten wie Verbindungen mit Hostmodul und/oder KWS sollte der Treiber ACX deaktivieren, um die Stream-Bridge-Handhabung zu verhindern und stattdessen eine Stream-Bridge ohne Inmode zu erstellen. Dieser Ansatz verhindert, dass ACX Streams automatisch Stream-Bridges zuordnet.

Weitere Informationen

Voice-Aktivierung