Condividi tramite

Assistente vocale multiplo

  • Articolo

La piattaforma Multiple Voice Assistant offre supporto per assistenti vocali aggiuntivi in Windows. Ciò consente la disponibilità di altri assistenti su dispositivi Windows, ad esempio PC e dispositivi indossabili come HoloLens. Più assistenti vocali possono essere attivi nello stesso dispositivo usando un set di modelli di parole chiave supportati.

Nota

L'assistente vocale multiplo è supportato a partire da Windows 10 versione 1903.

Per informazioni sull'implementazione di Windows Cortana, vedi Attivazione vocale.

Attivazione vocale

L'attivazione vocale è una funzionalità che consente agli utenti di richiamare un motore di riconoscimento vocale da vari stati di alimentazione del dispositivo pronunciando una frase specifica.

L'implementazione dell'attivazione vocale è un progetto significativo ed è un'attività completata dai fornitori soC. Gli OEM possono contattare il fornitore soC per informazioni sull'implementazione dell'attivazione vocale del SoC.

L'attivazione vocale consente agli utenti di interagire rapidamente con l'esperienza dell'assistente vocale al di fuori del contesto attivo (ad esempio, ciò che è attualmente sullo schermo) usando la voce. Gli utenti spesso vogliono poter accedere immediatamente a un'esperienza senza dover interagire fisicamente con o toccare un dispositivo. Per un utente Xbox, questo potrebbe non voler trovare e connettere un controller. Per gli utenti del PC, potrebbero voler accedere rapidamente a un'esperienza senza dover eseguire più azioni tramite mouse, tocco e/o tastiera, come nel caso di un computer in cucina.

L'attivazione vocale è basata su un rilevatore di parole chiave (KWS) che reagisce se viene rilevata la frase chiave. Le frasi chiave possono includere parole chiave, ad esempio "Hey Contoso". Il rilevamento delle parole chiave descrive il rilevamento della parola chiave da hardware o software.

Le frasi chiave possono essere pronunciate da se stessi ("Hey Contoso") come comando a fasi o seguite da un'azione vocale che compone un comando concatenato ("Hey Contoso, dove è la riunione successiva?")

Microsoft fornisce un spotter di parole chiave predefinito del sistema operativo (spotter parola chiave software) per offrire un'esperienza di assistente vocale nei casi in cui il rilevamento delle parole chiave hardware non è disponibile. Sebbene sia attualmente disponibile per Cortana, potrebbe essere necessaria una configurazione Microsoft aggiuntiva per eseguire l'onboarding di altri assistenti vocali per eseguire il rilevamento di parole chiave in due fasi. Per altre informazioni, contattare AskMVA@Microsoft.com.

Se KWS deve riattivare il dispositivo da uno stato a basso consumo, la soluzione è nota come Wake-on-Voice (WoV). Per altre informazioni, vedere Riattivazione vocale più avanti in questo articolo.

Glossario dei termini

Questo glossario riepiloga i termini correlati all'attivazione vocale.

Termine Esempio/definizione
Comando a fasi Esempio: Hey Contoso <sospende, aspetta l'interfaccia utente> dell'assistente Qual è il meteo? Questa operazione viene talvolta definita "comando a due scatti" o "solo parola chiave".
Comando concatenato Esempio: Hey Contoso che cos'è il tempo? Questa operazione viene talvolta definita "comando a colpo singolo".
Attivazione vocale Esempio: "Hey Contoso" Scenario in cui viene rilevata la parola chiave in una frase chiave di attivazione predefinita.
Riattivazione vocale (WoV) Tecnologia che consente l'attivazione vocale da uno schermo spento, uno stato di alimentazione inferiore, a uno schermo con stato di alimentazione completa.
WoV da Standby moderno Riattivazione vocale da uno stato di standby moderno (S0ix) a uno stato di alimentazione completa (S0).
Standby moderno Infrastruttura di Inattività di Windows Low Power: successore di Connessione ed Standby (CS) in Windows 10. Il primo stato di standby moderno è quando lo schermo è spento. Lo stato di sospensione più profondo è quando si trova in DRIPS/Resilienza. Per altre informazioni, vedere Standby moderno.
KWS Spotter parola chiave: algoritmo che fornisce il rilevamento di "Hey Contoso".
SW KWS Spotter parola chiave software: implementazione di KWS in esecuzione nell'host (CPU). Per "Hey Cortana", SW KWS è incluso come parte di Windows.
HW KWS Spotter di parole chiave hardware: implementazione di KWS che viene eseguita offloaded su hardware.
Buffer burst Buffer circolare usato per archiviare i dati PCM che possono scoppiare in caso di rilevamento KWS, in modo che sia incluso tutto l'audio che ha attivato un rilevamento KWS.
Adattatore OEM rilevamento eventi Componente in modalità utente che funge da intermediario tra lo stack di assistente vocale di Windows e il driver.
Modello File di dati del modello acustico usato dall'algoritmo KWS. Il file di dati è statico. I modelli vengono localizzati, uno per ogni impostazione locale.
MVA Più agenti vocali- HWKWS DDI che supportano più agenti.
SVA Single Voice Agent : precedente HWKWS DDI che supporta solo un singolo agente (Cortana).

Integrazione di un spotter di parole chiave hardware

Per implementare un rilevatore di parole chiave hardware (HW KWS) i fornitori di soC devono completare le attività seguenti.

Requisiti woV per parole chiave offloaded hardware (HW KWS)

  • HW KWS WoV è supportato durante lo stato di lavoro S0 e lo stato di sospensione S0 noto anche come Standby moderno.
  • HW KWS WoV non è supportato da S3.

AEC

AEC può essere eseguito dal DSP al momento dell'acquisizione dell'audio burst oppure può essere eseguito in un secondo momento tramite un software APO. Per eseguire un software AEC con dati burst KWS, è necessario avere l'audio di loopback corrispondente dal momento in cui sono stati acquisiti i dati burst. A tale scopo, è stato creato un formato audio personalizzato per l'output burst che interlea l'audio di loopback nei dati audio burst.

A partire da Windows versione 20H1, Microsoft AEC APO è a conoscenza di questo formato interleaved e può usarlo per eseguire AEC. Per altre informazioni, vedere KSPROPERTY_INTERLEAVEDAUDIO_FORMATINFORMATION.

Convalida

Convalidare il supporto HW per le proprietà KSPROP edizione Standard TID_SoundDetector2 con i test di Voice Activation Manager 2.

Panoramica del codice di esempio

È disponibile un codice di esempio per un driver audio che implementa l'attivazione vocale in GitHub come parte dell'esempio di adattatore audio virtuale SYSVAD. È consigliabile usare questo codice come punto di partenza.

Per altre informazioni sul driver audio di esempio SYSVAD, vedere Driver audio di esempio.

Informazioni sul sistema di riconoscimento delle parole chiave

Supporto dello stack audio di attivazione vocale

Le interfacce esterne dello stack audio per l'abilitazione dell'attivazione vocale fungono da pipeline di comunicazione per la piattaforma di riconoscimento vocale e i driver audio. Le interfacce esterne sono suddivise in tre parti.

  • DDI (Device Driver Interface) del rilevatore di eventi. L'interfaccia del driver di dispositivo rilevamento eventi è responsabile della configurazione e dell'arming di HW Keyword Spotter (KWS). Viene usato anche dal driver per notificare al sistema un evento di rilevamento.
  • DLL dell'adattatore OEM IEvent Detector. Questa DLL implementa un'interfaccia COM per adattare i dati opachi specifici del driver da usare dal sistema operativo per facilitare il rilevamento delle parole chiave.
  • Miglioramenti waveRT. I miglioramenti consentono al driver audio di trasmettere in streaming i dati audio memorizzati nel buffer dal rilevamento delle parole chiave.

Proprietà dell'endpoint audio

La compilazione del grafico dell'endpoint audio si verifica normalmente. Il grafico è preparato per gestire più velocemente rispetto all'acquisizione in tempo reale. I timestamp nei buffer acquisiti rimangono true. In particolare, i timestamp rifletteranno correttamente i dati acquisiti in passato e memorizzati nel buffer e che ora sono in fase di bursting.

Teoria del bypass bluetooth dello streaming audio

Il driver espone un filtro KS per il dispositivo di acquisizione come di consueto. Questo filtro supporta diverse proprietà KS e un evento KS da configurare, abilitare e segnalare un evento di rilevamento. Il filtro include anche una factory di pin aggiuntiva identificata come pin spotter (KWS) con parole chiave. Questo pin viene usato per trasmettere l'audio dallo spotter della parola chiave.

La proprietà è: KSPROP edizione Standard TID_SoundDetector2

Tutte le proprietà KSPROP edizione Standard TID_SoundDetector2 vengono chiamate con una struttura di dati KSSOUNDDETECTORPROPERTY. Questa struttura di dati contiene un KSPROPERTY e l'ID evento per la parola chiave da armare, reimpostare, rilevare e così via.

  • Tipi di parole chiave supportati: KSPROPERTY_SOUNDDETECTOR_PATTERNS. Questa proprietà viene impostata dal sistema operativo per configurare le parole chiave da rilevare.
  • Elenco dei GUID dei modelli di parole chiave : KSPROPERTY_SOUNDDETECTOR_SUPPORTEDPATTERNS. Questa proprietà viene usata per ottenere un elenco di GUID che identificano i tipi di modelli supportati.
  • Armato - KSPROPERTY_SOUNDDETECTOR_ARMED. Questa proprietà di lettura/scrittura è semplicemente uno stato booleano che indica se il rilevatore è armato. Il sistema operativo imposta questa opzione per coinvolgere il rilevatore di parole chiave. Il sistema operativo può cancellare questo problema per disattivare. Il driver cancella automaticamente questo valore quando vengono impostati i modelli di parole chiave e anche dopo che viene rilevata una parola chiave. Il sistema operativo deve riprovare.
  • Risultato della corrispondenza: KSPROPERTY_SOUNDDETECTOR_RE edizione Standard T viene usato per reimpostare il rilevatore audio in fase di avvio.

Al momento del rilevamento delle parole chiave, viene inviata una notifica PNP contenente KSNOTIFICATIONID_SoundDetector. NOTA: questo non è un evento K edizione Standard, ma piuttosto un evento PNP che viene inviato, con un payload, tramite IoReportTargetDeviceChangeAsynchronous.

KSNOTIFICATIONID_SoundDetector è definito in ksmedia.h, come illustrato di seguito.

// 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)

Sequenza di operazioni

Avvio del sistema

  1. Il sistema operativo invia un KSPROPERTY_SOUNDDETECTOR_RE edizione Standard T per cancellare qualsiasi stato di rilevamento precedente, reimpostando tutti i rilevatori in modo da disarmare e cancellare i modelli precedenti impostati.
  2. Il sistema operativo esegue una query KSPROPERTY_SOUNDDETECTOR_PATTERNS per recuperare il clsid per l'adattatore OEM del rilevatore eventi.
  3. Il sistema operativo usa l'adattatore OEM rilevamento eventi per recuperare l'elenco di parole chiave e lingue supportate.
  4. Il sistema operativo esegue la registrazione per le notifiche PNP personalizzate inviate dal driver
  5. Il sistema operativo imposta i criteri di parola chiave obbligatori.
  6. Il sistema operativo armerà i rilevatori

Funzionamento interno di driver e hardware

Mentre il rilevatore è armato, l'hardware può essere costantemente acquisito e memorizzare nel buffer i dati audio in un piccolo buffer FIFO. Le dimensioni di questo buffer FIFO sono determinate dai requisiti al di fuori di questo documento, ma in genere possono essere centinaia di millisecondi fino a diversi secondi. L'algoritmo di rilevamento opera sul flusso di dati tramite questo buffer. La progettazione del driver e dell'hardware è tale che, mentre armato non vi è alcuna interazione tra il driver e l'hardware e non interrompe i processori "applicazione" fino a quando non viene rilevata una parola chiave. Ciò consente al sistema di raggiungere uno stato di alimentazione inferiore se non è presente alcuna altra attività.

Quando l'hardware rileva una parola chiave, genera un interrupt. Durante l'attesa del servizio dell'interrupt da parte del driver, l'hardware continua a acquisire l'audio nel buffer, assicurando che non vengano persi dati dopo la perdita della parola chiave, entro i limiti di buffering.

Timestamp parola chiave

Dopo aver rilevato una parola chiave, tutte le soluzioni di attivazione vocale devono memorizzare nel buffer tutte le parole chiave pronunciate, incluse le 1.6s prima dell'inizio della parola chiave. Il driver audio deve fornire timestamp che identificano l'inizio e la fine della frase chiave nel flusso.

Per supportare i timestamp di inizio/fine della parola chiave, il software DSP potrebbe dover eseguire internamente eventi timestamp in base a un orologio DSP. Una volta rilevata una parola chiave, il software DSP interagisce con il driver per preparare un evento KS. Il driver e il software DSP dovranno eseguire il mapping dei timestamp DSP a un valore del contatore delle prestazioni di Windows. Il metodo di questa operazione è specifico per la progettazione hardware. Una possibile soluzione consiste nel fatto che il driver legge il contatore delle prestazioni corrente, esegue una query sul timestamp DSP corrente, legge di nuovo il contatore delle prestazioni corrente e quindi stima una correlazione tra il contatore delle prestazioni e l'ora DSP. Data quindi la correlazione, il driver può eseguire il mapping dei timestamp della parola chiave DSP ai timestamp del contatore delle prestazioni di Windows.

Interfaccia dell'adattatore OEM del rilevatore IEvent

L'OEM fornisce un'implementazione dell'oggetto COM che funge da intermediario tra il sistema operativo e il driver, consentendo di calcolare o analizzare i dati opachi scritti e letti nel driver audio tramite KSPROPERTY_SOUNDDETECTOR_PATTERNS e KSPROPERTY_SOUNDDETECTOR_MATCHRESULT.

Il CLSID dell'oggetto COM è un GUID del tipo di modello di rilevamento restituito dal KSPROPERTY_SOUNDDETECTOR_SUPPORTEDPATTERNS. Il sistema operativo chiama CoCreateInstance passando il GUID del tipo di pattern per creare un'istanza dell'oggetto COM appropriato compatibile con il tipo di pattern di parole chiave e chiama i metodi sull'interfaccia IEventDetectorOemAdapter dell'oggetto.

Requisiti del modello di threading COM

L'implementazione dell'OEM può scegliere uno dei modelli di threading COM.

IEventDetectorOemAdapter

La progettazione dell'interfaccia tenta di mantenere l'implementazione dell'oggetto senza stato. In altre parole, l'implementazione non deve richiedere l'archiviazione di alcuno stato tra le chiamate al metodo. Infatti, le classi C++ interne probabilmente non necessitano di variabili membro oltre a quelle necessarie per implementare un oggetto COM in generale.

Metodi

Implementare i metodi seguenti.

Miglioramenti di WAVERT

Le interfacce miniport sono definite per essere implementate dai driver miniport WaveRT. Queste interfacce forniscono metodi per semplificare il driver audio, migliorare le prestazioni e l'affidabilità della pipeline audio del sistema operativo o supportare nuovi scenari. Viene definita una proprietà dell'interfaccia del dispositivo PnP che consente al driver di fornire un'espressione statica dei vincoli di dimensione del buffer al sistema operativo.

Dimensioni buffer

Un driver opera in vari vincoli quando si spostano dati audio tra il sistema operativo, il driver e l'hardware. Questi vincoli possono essere dovuti al trasporto hardware fisico che sposta i dati tra memoria e hardware e/o a causa dei moduli di elaborazione dei segnali all'interno dell'hardware o del DSP associato.

Le soluzioni HW-KWS devono supportare dimensioni di acquisizione audio di almeno 100 ms e fino a 200 ms.

Il driver esprime i vincoli di dimensione del buffer impostando la proprietà del dispositivo DEVPKEY_KsAudio_PacketSize_Constraints2 nell'interfaccia del dispositivo PnP KSCATEGORY_AUDIO del filtro KS con i pin di streaming KS. Questa proprietà deve rimanere valida e stabile mentre l'interfaccia del filtro KS è abilitata. Il sistema operativo può leggere questo valore in qualsiasi momento senza dover aprire un handle al driver e chiamare sul driver.

DEVPKEY_KsAudio_PacketSize_Constraints2

Il valore della proprietà DEVPKEY_KsAudio_PacketSize_Constraints2 contiene una struttura KSAUDIO_PACKETSIZE_CONSTRAINTS2 che descrive i vincoli hardware fisici ,ad esempio a causa della meccanica del trasferimento dei dati dal buffer WaveRT all'hardware audio. La struttura include una matrice di 0 o più strutture KSAUDIO_PACKETSIZE_PROCESSINGMODE_CONSTRAINT che descrivono vincoli specifici di qualsiasi modalità di elaborazione dei segnali. Il driver imposta questa proprietà prima di chiamare PcRegisterSubdevice o abilitare in altro modo l'interfaccia del filtro KS per i pin di streaming.

IMiniportWaveRTInputStream

Un driver implementa questa interfaccia per un migliore coordinamento del flusso di dati audio dal driver al sistema operativo. Se questa interfaccia è disponibile in un flusso di acquisizione, il sistema operativo usa metodi su questa interfaccia per accedere ai dati nel buffer WaveRT. Per altre informazioni, vedere IMiniportWaveRTInputStream ::GetReadPacket

IMiniportWaveRTOutputStream

Un miniport WaveRT implementa facoltativamente questa interfaccia per essere avvisata dello stato di avanzamento della scrittura dal sistema operativo e per restituire una posizione precisa del flusso. Per altre informazioni, vedere IMiniportWaveRTOutputStream::SetWritePacket, IMiniportWaveRTOutputStream::GetOutputStreamPresentationPosition e IMiniportWaveRTOutputStream::GetPacketCount.

Timestamp del contatore delle prestazioni

Diverse routine del driver restituiscono timestamp del contatore delle prestazioni di Windows che riflettono il tempo in cui gli esempi vengono acquisiti o presentati dal dispositivo.

Nei dispositivi che dispongono di pipeline DSP complesse e elaborazione dei segnali, il calcolo di un timestamp accurato può essere complesso e deve essere eseguito attentamente. I timestamp non devono semplicemente riflettere il momento in cui i campioni sono stati trasferiti dal sistema operativo al DSP.

  • All'interno del provider di servizi di dominio tenere traccia dei timestamp di esempio usando un orologio interno DSP.
  • Tra il driver e il DSP, calcolare una correlazione tra il contatore delle prestazioni di Windows e l'orologio a parete DSP. Le procedure per questo possono variare da molto semplice (ma meno preciso) a piuttosto complesso o romanzo (ma più preciso).
  • Tenere conto di eventuali ritardi costanti dovuti ad algoritmi di elaborazione dei segnali o a trasporti hardware o pipeline, a meno che questi ritardi non vengano altrimenti rilevati.

Operazione di lettura burst

Questa sezione descrive l'interazione del sistema operativo e del driver per le letture burst. La lettura burst può verificarsi all'esterno dello scenario di attivazione vocale, purché il driver supporti il modello WaveRT di streaming basato su pacchetti, inclusa la funzione IMiniportWaveRTInputStream::GetReadPacket.

Vengono illustrati due scenari di lettura di esempio burst. In uno scenario, se il miniport supporta un pin con categoria pin KSNODETYPE_AUDIO_KEYWORDDETECTOR , il driver inizierà l'acquisizione e il buffering interno dei dati quando viene rilevata una parola chiave. In un altro scenario, il driver può facoltativamente memorizzare nel buffer i dati del buffer WaveRT all'esterno del buffer WaveRT se il sistema operativo non legge i dati abbastanza rapidamente chiamando IMiniportWaveRTInputStream::GetReadPacket.

Per eseguire il burst dei dati acquisiti prima della transizione a KSSTATE_RUN, il driver deve conservare informazioni accurate sul timestamp di esempio insieme ai dati di acquisizione memorizzati nel buffer. I timestamp identificano l'istante di campionamento degli esempi acquisiti.

  1. Dopo che il flusso passa a KSSTATE_RUN, il driver imposta immediatamente l'evento di notifica del buffer perché contiene già dati disponibili.

  2. In questo evento il sistema operativo chiama GetReadPacket() per ottenere informazioni sui dati disponibili.

    a. Il driver restituisce il numero di pacchetti dei dati acquisiti validi (0 per il primo pacchetto dopo la transizione da KSSTATE_STOP a KSSTATE_RUN), da cui il sistema operativo può derivare la posizione del pacchetto all'interno del buffer WaveRT, nonché la posizione del pacchetto rispetto all'inizio del flusso.

    b. Il driver restituisce anche il valore del contatore delle prestazioni che corrisponde all'istante di campionamento del primo campione nel pacchetto. Si noti che questo valore del contatore delle prestazioni potrebbe essere relativamente vecchio, a seconda della quantità di dati di acquisizione memorizzati nel buffer hardware o driver (all'esterno del buffer WaveRT).

    c. Se sono disponibili più dati memorizzati nel buffer non letti, il driver è: i. Trasferisce immediatamente i dati nello spazio disponibile del buffer WaveRT (ovvero lo spazio non utilizzato dal pacchetto restituito da GetReadPacket), restituisce true per MoreData e imposta l'evento di notifica del buffer prima di tornare da questa routine. O, ii. Programmi hardware per eseguire il burst del pacchetto successivo nello spazio disponibile del buffer WaveRT, restituisce false per MoreData e successivamente imposta l'evento buffer al termine del trasferimento.

  3. Il sistema operativo legge i dati dal buffer WaveRT usando le informazioni restituite da GetReadPacket().

  4. Il sistema operativo attende l'evento di notifica del buffer successivo. L'attesa potrebbe terminare immediatamente se il driver imposta la notifica del buffer nel passaggio (2c).

  5. Se il driver non ha impostato immediatamente l'evento nel passaggio (2c), il driver imposta l'evento dopo che trasferisce più dati acquisiti nel buffer WaveRT e lo rende disponibile per la lettura del sistema operativo

  6. Vai a (2).

Per KSNODETYPE_AUDIO_KEYWORDDETECTOR pin del rilevatore di parole chiave, i driver devono allocare un buffer di burst interno sufficiente per almeno 5000 ms di dati audio. Se il sistema operativo non riesce a creare un flusso sul pin prima dell'overflow del buffer, il driver potrebbe terminare l'attività di buffering interna e liberare le risorse associate.

Riattivazione vocale

Wake-on-Voice (WoV) consente all'utente di attivare ed eseguire query su un motore di riconoscimento vocale da uno stato di basso consumo a uno stato di alimentazione completa con schermo attivo dicendo una determinata parola chiave, ad esempio "Hey Contoso".

Questa funzionalità consente al dispositivo di essere sempre in ascolto della voce dell'utente mentre il dispositivo è inattivo e lo schermo è spento. Questo è dovuto alla modalità di ascolto che usa molto meno potenza rispetto alla normale registrazione del microfono. WoV consente di concatenare la frase vocale come "Hey Contoso, quando è il mio prossimo appuntamento" per richiamare una risposta da un assistente vocale in modo pratico.

Lo stack audio è responsabile della comunicazione dei dati di riattivazione (ID voce, trigger di parole chiave, informazioni sul contesto a livello di attendibilità) e notifica ai client interessati che la parola chiave è stata rilevata.

Convalida nei sistemi di standby moderni

WoV da uno stato di inattività del sistema può essere convalidato nei sistemi di standby moderni usando il test di base di riattivazione standby moderno sull'origine di alimentazione AC e la riattivazione standby moderna sul test di base della voce sull'originedi alimentazione DC in HLK. Questi test verificano che il sistema disponga di un rilevatore di parole chiave hardware (HW-KWS), sia in grado di immettere lo stato della piattaforma DRIPS (Deepest Runtime Idle Platform State) ed è in grado di riattivare da Modern Standby nel comando vocale con latenza di ripresa del sistema inferiore o uguale a un secondo.

ACX e MVA

Audio Class eXtension (ACX) definisce un'estensione di classe WDF (Windows Driver Framework) per il dominio audio. Per altre informazioni su ACX, vedere Panoramica delle estensioni della classe audio ACX e Riepilogo degli oggetti ACX. Questa sezione descrive come implementare MVA usando ACX.

ACX usa la stessa infrastruttura KS per lo spotter parola chiave, aggiungendo un livello di astrazione per semplificare l'implementazione del driver. Con ACX la stessa DLL OEM viene usata come descritto in precedenza e rimane invariata. Sia ACX che Portcl richiedono l'interfaccia IEventDetectorOEMAdapter e non esiste alcuna differenza nell'implementazione tra i due per la scheda OEM.

La funzione AcxKeywordSpotterCreate viene usata per creare un oggetto opaco a parole chiave ACX (ACXKEYWORDSPOTTER) che verrà associato a un elemento padre dell'oggetto dispositivo circuito.

L'oggetto ACXKEYWORDSPOTTER viene usato per sostituire tutte le chiamate KSPROPERTY_SOUNDDETECTOR, semplificando l'implementazione di KWS. Viene usato nel processo di aggiunta di un elemento KWS e un pin KWS al circuito ACX. I callback associati si occupano di ottenere i modelli, arming, disarmare e reimpostare. Usa una struttura di ACX_KEYWORDSPOTTER_CONFIG inizializzata che descrive la configurazione dell'identificatore di parola chiave.

La struttura ACX_KEYWORDSPOTTER_CONFIG accetta una struttura ACX_KEYWORDSPOTTER_CALLBACKS che definisce i callback seguenti.

EvtAcxKeywordSpotterRetrieveArm - Callback ACX_KEYWORDSPOTTER_RETRIEVE_ARM .

EvtAcxKeywordSpotterAssignArm: callback ACX_KEYWORDSPOTTER_ASSIGN_ARM .

EvtAcxKeywordSpotterAssignPatterns - Callback ACX_KEYWORDSPOTTER_ASSIGN_PATTERNS .

EvtAcxKeywordSpotterAssignReset: callback ACX_KEYWORDSPOTTER_ASSIGN_RE edizione Standard T.

ACX PNP, evento

L'evento PNP ACX sostituisce KSNOTIFICATIONID_SoundDetector, semplificando l'evento di notifica di rilevamento. La funzione ACX_PNPEVENT_CONFIG_INIT inizializza una struttura ACX_PNPEVENT_CONFIG. Nessun input viene usato con questa funzione.

Codice di esempio ACX KWS

Il codice di esempio ACX KWS mostra l'inizializzazione dei callback, degli elementi delle parole chiave e della creazione del spotter della parola chiave.

{
    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;

Successivamente viene usata la funzione AcxKeywordSpotterCreate per creare l'oggetto spotter della parola chiave ACX e associarlo a un circuito esistente.

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

Il contesto spotter parola chiave viene quindi determinato e usato per creare keywordDetector nella memoria NonPagedPoolNx.

    
    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 questo codice di esempio, la classe CKeywordDetector aggiunta al contesto viene fornita solo come implementazione di esempio che simula la ricerca di parole chiave all'interno del driver di esempio. La classe CKeywordDetector non fa parte del framework ACX o di una parte necessaria dell'implementazione di MVA in ACX, ma può fornire un buon punto di partenza per lo sviluppo di un indicatore di parole chiave effettivo.

Infine, l'evento ACX PnP viene configurato e creato.

   
    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;

}

Circuiti con comportamento di pin complesso, inclusi KWS

Per i circuiti con comportamento di pin complesso, ad esempio circuiti con motore host e/o KWS, il driver deve disabilitare ACX per eseguire la gestione del bridge di flusso e creare invece un bridge di flusso senza inmode. Questo approccio impedirà a ACX di associare automaticamente i flussi ai bridge di flusso.

Vedi anche

Attivazione vocale