Attivazione vocale

Nota

Questo argomento si riferisce principalmente alle esperienze degli utenti, attualmente distribuite in Windows 10 (versione 1909 e precedenti) Per altre informazioni, vedere Fine del supporto per Cortana in Windows e Teams.

Cortana, la tecnologia di assistente personale è stata illustrata per la prima volta alla Microsoft BUILD Developer Conference nel 2013. La piattaforma di riconoscimento vocale Windows viene usata per alimentare tutte le esperienze vocali in Windows 10, ad esempio Cortana e Dettatura. 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: "Ehi Cortana". Per creare hardware che supporti la tecnologia di attivazione vocale, esaminare le informazioni contenute in questo argomento.

Nota

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 di SoC dell'attivazione vocale.

Esperienza utente finale di Cortana

Per comprendere l'esperienza di interazione vocale disponibile in Windows, esaminare questi argomenti.

Argomento	Descrizione
Cos'è Cortana?	Fornisce e panoramica e direzione di utilizzo per Cortana

Introduzione all'attivazione vocale di "Hey Cortana" e "Learn my voice"

Attivazione vocale di Hey Cortana

La funzionalità di attivazione vocale di "Hey Cortana" consente agli utenti di interagire rapidamente con l'esperienza cortana al di fuori del contesto attivo (ad esempio, ciò che è attualmente sullo schermo) usando la voce. Gli utenti spesso vogliono essere in grado di accedere immediatamente a un'esperienza senza dover interagire fisicamente con un dispositivo. Per gli utenti del telefono questo può essere dovuto alla guida in auto e avere la loro attenzione e le mani impegnati con il funzionamento del veicolo. Per un utente Xbox questo potrebbe non voler trovare e connettere un controller. Per gli utenti di PC, questo può essere dovuto a un accesso rapido a un'esperienza senza dover eseguire più azioni del mouse, tocco e/o tastiera, ad esempio un computer in cucina.

L'attivazione vocale fornisce sempre l'input vocale in ascolto tramite frasi chiave predefinite o frasi di attivazione. Le frasi chiave possono essere pronunciate da se stessi ("Ehi Cortana") come comando a fasi o seguite da un'azione di riconoscimento vocale, ad esempio "Ehi Cortana, dove è la mia riunione successiva?", un comando concatenato.

Il termine Rilevamento parole chiave descrive il rilevamento della parola chiave tramite hardware o software.

L'attivazione della parola chiave si verifica solo quando si dice solo la parola chiave Cortana, Cortana avvia e riproduce il suono EarCon per indicare che è entrato in modalità di ascolto.

Un comando concatenato descrive la possibilità di eseguire un comando immediatamente dopo la parola chiave (ad esempio "Ehi Cortana, chiamare John") e avviare Cortana (se non è già stato avviato) e seguire il comando (avviando una chiamata telefonica con John).

Questo diagramma illustra l'attivazione concatenata e con parole chiave.

Microsoft fornisce uno spotter di parole chiave predefinito del sistema operativo (spotter di parole chiave software) usato per garantire la qualità dei rilevamenti delle parole chiave hardware e fornire l'esperienza Di cortana hey nei casi in cui il rilevamento delle parole chiave hardware è assente o non disponibile.

Funzionalità "Learn my voice"

La funzionalità "Learn my voice" consente all'utente di eseguire il training di Cortana per riconoscere la voce unica. Questa operazione viene eseguita dall'utente selezionando Learn how I say "Hey Cortana" (Ehi Cortana) nella schermata delle impostazioni di Cortana. L'utente ripete quindi sei frasi scelte con attenzione che forniscono una varietà sufficiente di modelli fonetici per identificare gli attributi univoci della voce degli utenti.

Quando l'attivazione vocale è associata a "Learn my voice", i due algoritmi funzionano insieme per ridurre le false attivazioni. Questo è particolarmente utile per lo scenario della sala riunioni, in cui una persona dice "Ehi Cortana" in una stanza piena di dispositivi. Questa funzionalità è disponibile solo per Windows 10 versione 1903 e precedenti.

L'attivazione vocale è basata su un rilevatore di parole chiave (KWS) che reagisce se viene rilevata la frase chiave. Se il KWS deve riattivare il dispositivo da uno stato a basso consumo, la soluzione è nota come Riattivazione vocale (WoV). Per altre informazioni, vedere Riattivazione vocale.

Glossario dei termini

Questo glossario riepiloga i termini relativi all'attivazione vocale.

Termine	Esempio/definizione
Comando a fasi	Esempio: Hey Cortana <sospende, aspetta earcon> What's the weather? Questa operazione viene talvolta definita "Comando a due colpi" o "Solo parola chiave"
Comando concatenato	Esempio: Ehi Cortana che cosa è il tempo? Questa operazione viene talvolta definita comando "One-shot"
Attivazione vocale	Scenario di rilevamento delle parole chiave di una keyphrase di attivazione predefinita. Ad esempio, "Hey Cortana" è lo scenario di attivazione vocale Microsoft.
WoV	Riattivazione vocale: tecnologia che consente l'attivazione vocale da uno schermo spento, stato di alimentazione inferiore, a uno schermo con stato di alimentazione completa.
WoV dallo 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 Connected 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 Modern Standby
KWS	Spotter parola chiave: l'algoritmo che fornisce il rilevamento di "Hey Cortana"
SW KWS	Spotter parola chiave software: implementazione di KWS in esecuzione nell'host (CPU). Per "Hey Cortana", SW KWS è incluso come parte di Windows.
KW HW	Spotter parola chiave offloaded hardware: un'implementazione di KWS che viene eseguita offloaded su hardware.
Burst Buffer	Buffer circolare usato per archiviare i dati PCM che possono essere "burst up" in caso di rilevamento KWS, in modo che sia incluso tutto l'audio che ha attivato un rilevamento KWS.
Adattatore OEM rilevamento parole chiave	Shim a livello di driver che consente al modulo di protezione hardware abilitato per WoV di comunicare con Windows e lo stack di Cortana.
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.

Integrazione di un spotter con parole chiave hardware

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

• Creare un rilevatore di parole chiave personalizzato basato sull'esempio SYSVAD descritto più avanti in questo argomento. Questi metodi verranno implementati in una DLL COM, descritta in Keyword Detector OEM Adapter Interface.
• Implementare miglioramenti WAVE RT descritti in Miglioramenti WAVERT.
• Specificare le voci del file INF per descrivere qualsiasi API personalizzata usata per il rilevamento delle parole chiave.
  • 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
• Esaminare le indicazioni sull'hardware e le linee guida per i test in Raccomandazione del dispositivo audio. Questo argomento fornisce indicazioni e consigli per la progettazione e lo sviluppo di dispositivi di input audio destinati all'uso con La piattaforma di riconoscimento vocale Microsoft.
• Supporta sia i comandi di staging che i comandi concatenati.
• Supporto di "Hey Cortana" per ognuna delle impostazioni locali di Cortana supportate.
• Le API (Oggetti elaborazione audio) devono fornire gli effetti seguenti:
  • AEC
  • AGC
  • NS
• Gli effetti per la modalità di elaborazione vocale devono essere segnalati dall'APO di MFX.
• L'APO può eseguire la conversione del formato come MFX.
• L'APO deve restituire il formato seguente:
  • 16 kHz, mono, FLOAT.
• Facoltativamente, progettare qualsiasi API personalizzata per migliorare il processo di acquisizione audio. Per altre informazioni, vedere Oggetti di elaborazione audio windows.

Requisiti della parola chiave offload hardware (HW KWS) WoV

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

Requisiti di AEC per HW KWS

• Per Windows versione 1709

  • Per supportare HW KWS WoV per lo stato di sospensione S0 (Standby moderno) AEC non è necessario.
  • HW KWS WoV per lo stato di lavoro S0 non è supportato in Windows Versione 1709.

• Per Windows versione 1803

  • HW KWS WoV per lo stato di lavoro S0 è supportato.
  • Per abilitare HW KWS WoV per lo stato di lavoro S0, l'APO deve supportare AEC.

Panoramica del codice di esempio

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

https://github.com/Microsoft/Windows-driver-samples/tree/main/audio/sysvad/

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

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 vocale e i driver audio. Le interfacce esterne sono suddivise in tre parti.

• Rilevamento parole chiave Dell'interfaccia del driver del dispositivo (DDI). L'interfaccia del driver del dispositivo di rilevamento delle parole chiave è 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 di Rilevamento parole chiave. 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 dello streaming WaveRT. I miglioramenti consentono al driver audio di eseguire il burst dei 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 l'acquisizione in tempo reale. I timestamp nei buffer acquisiti rimangono true. In particolare, i timestamp riflettono correttamente i dati acquisiti in passato e memorizzati nel buffer ed è ora "bursting".

Teoria del bypass bluetooth di 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 fabbrica di pin aggiuntiva identificata come pin di parola chiave (KWS). Questo pin viene usato per trasmettere l'audio dallo spotter della parola chiave.

Le proprietà sono:

• Tipi di parole chiave supportati: KSPROPERTY_SOUNDDETECTOR_PATTERNS. Questa proprietà è 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 questo valore per coinvolgere il rilevamento delle parole chiave. Il sistema operativo può cancellare questa operazione per sganciare. Il driver cancella automaticamente questo problema quando vengono impostati i modelli di parole chiave e anche dopo che viene rilevata una parola chiave. Il sistema operativo deve riordinare.
• Risultato della corrispondenza: KSPROPERTY_SOUNDDETECTOR_MATCHRESULT. Questa proprietà di lettura contiene i dati dei risultati dopo che si è verificato il rilevamento.

L'evento generato quando viene rilevata una parola chiave è un evento KSEVENT_SOUNDDETECTOR_MATCHDETECTED .

Sequenza di operazione

Avvio del sistema

1. Il sistema operativo legge i tipi di parole chiave supportati per verificare che abbia parole chiave in tale formato.
2. Il sistema operativo registra per l'evento di modifica dello stato del rilevamento.
3. Il sistema operativo imposta i modelli di parole chiave.
4. Il sistema operativo arma il rilevatore.

Ricezione dell'evento KS

1. Il conducente disarma il rilevatore.
2. Il sistema operativo legge lo stato del rilevatore di parole chiave, analizza i dati restituiti e determina quale modello è stato rilevato.
3. Il sistema operativo riorganizzerà il rilevatore.

Funzionamento interno del driver e dell'hardware

Mentre il rilevatore è armato, l'hardware può essere continuamente acquisito e buffering di dati audio in un piccolo buffer FIFO. Le dimensioni di questo buffer FIFO sono determinate dai requisiti esterni a questo documento, ma potrebbero in genere essere centinaia di millisecondi 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 esiste 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 interruzione. Durante l'attesa del driver per il servizio dell'interruzione, l'hardware continua a acquisire l'audio nel buffer, garantendo che non vengano persi dati dopo la perdita della parola chiave, entro i limiti di buffering.

Timestamp delle parole chiave

Dopo aver rilevato una parola chiave, tutte le soluzioni di attivazione vocale devono bufferare tutte le parole chiave parlato, incluse 250ms 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 gli eventi timestamp in base a un orologio DSP. Dopo aver rilevato 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 leggere il contatore delle prestazioni corrente, eseguire una query sul timestamp DSP corrente, leggere di nuovo il contatore delle prestazioni correnti e quindi stimare una correlazione tra il contatore delle prestazioni e il tempo DSP. Data quindi la correlazione, il driver può eseguire il mapping dei timestamp DSP della parola chiave ai timestamp dei contatori delle prestazioni di Windows.

Interfaccia dell'adattatore OEM di Rilevamento parole chiave

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.

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 modello per creare un'istanza dell'oggetto COM appropriato compatibile con il tipo di modello di parola chiave e chiama i metodi nell'interfaccia IKeywordDetectorOemAdapter dell'oggetto.

Requisiti del modello di threading COM

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

IKeywordDetectorOemAdapter

La progettazione dell'interfaccia tenta di mantenere senza stato l'implementazione dell'oggetto. In altre parole, l'implementazione non deve essere archiviata 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.

• IKeywordDetectorOemAdapter::BuildArmingPatternData
• IKeywordDetectorOemAdapter::ComputeAndAddUserModelData
• IKeywordDetectorOemAdapter::GetCapabilities
• IKeywordDetectorOemAdapter::P arseDetectionResultData
• IKeywordDetectorOemAdapter::VerifyUserKeyword

KEYWORDID

L'enumerazione KEYWORDID identifica il testo/la funzione della frase di una parola chiave e viene usato anche nelle schede del servizio biometrico di Windows. Per altre informazioni, vedere Panoramica di Biometric Framework - Componenti della piattaforma core

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

KEYWORDSELECTOR

Lo struct KEYWORDSELECTOR è un set di ID che selezionano in modo univoco una parola chiave e una lingua specifiche.

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

Gestione dei dati del modello

Modello indipendente dall'utente statico : la DLL OEM include in genere alcuni dati del modello indipendente dall'utente statico incorporati nella DLL o in un file di dati separato incluso nella DLL. Il set di ID parola chiave supportati restituiti dalla routine GetCapabilities dipende da questi dati. Ad esempio, se l'elenco degli ID di parole chiave supportati restituiti da GetCapabilities include KwHeyCortana, i dati del modello indipendente dall'utente statico includono i dati per "Hey Cortana" (o la relativa traduzione) per tutte le lingue supportate.

Modello dipendente dall'utente dinamico : IStream fornisce un modello di archiviazione di accesso casuale. Il sistema operativo passa un puntatore dell'interfaccia IStream a molti dei metodi nell'interfaccia IKeywordDetectorOemAdapter. Il sistema operativo esegue il backup dell'implementazione IStream con archiviazione appropriata per un massimo di 1 MB di dati.

Il contenuto e la struttura dei dati all'interno di questa risorsa di archiviazione sono definiti dall'OEM. Lo scopo previsto è l'archiviazione permanente dei dati del modello dipendente dall'utente calcolati o recuperati dalla DLL OEM.

Il sistema operativo può chiamare i metodi di interfaccia con un IStream vuoto, in particolare se l'utente non ha mai eseguito il training di una parola chiave. Il sistema operativo crea un'archiviazione IStream separata per ogni utente. In altre parole, un determinato IStream archivia i dati del modello per uno e un solo utente.

Lo sviluppatore DLL OEM decide come gestire i dati dipendenti dall'utente indipendenti dall'utente e dall'utente. Tuttavia, non archivierà mai i dati utente all'esterno dell'IStream. Una possibile progettazione DLL OEM passa internamente tra l'accesso a IStream e i dati indipendenti dall'utente statico a seconda dei parametri del metodo corrente. Una progettazione alternativa potrebbe controllare IStream all'inizio di ogni chiamata di metodo e aggiungere i dati indipendenti dall'utente statico al IStream, se non già presente, consentendo al resto del metodo di accedere solo ai dati IStream per tutti i dati del modello.

Elaborazione audio di training e operazione

Come descritto in precedenza, il flusso dell'interfaccia utente di training comporta la disponibilità di frasi complete fonetiche nel flusso audio. Ogni frase viene passata singolarmente a IKeywordDetectorOemAdapter::VerifyUserKeyword per verificare che contenga la parola chiave prevista e abbia una qualità accettabile. Dopo che tutte le frasi vengono raccolte e verificate dall'interfaccia utente, vengono passate tutte in una chiamata a IKeywordDetectorOemAdapter::ComputeAndAddUserModelData.

L'audio viene elaborato in modo univoco per il training dell'attivazione vocale. Nella tabella seguente vengono riepilogate le differenze tra il training di attivazione vocale e l'utilizzo regolare del riconoscimento vocale.

|

	Training vocale	Riconoscimento vocale
Modalità	Notifica non elaborata	Voce non elaborata o vocale
Spilla	Normale	KWS
Formato audio	Float a 32 bit (Tipo = Audio, Sottotipo = IEEE_FLOAT, Frequenza di campionamento = 16 kHz, bit = 32)	Gestito dallo stack audio del sistema operativo
Microfono	Mic 0	Tutti i microfoni nella matrice o mono

Panoramica del sistema di riconoscimento delle parole chiave

Questo diagramma offre una panoramica del sistema di riconoscimento delle parole chiave.

Diagrammi sequenza di riconoscimento delle parole chiave

In questi diagrammi viene visualizzato il modulo di runtime del riconoscimento vocale come "piattaforma voce". Come accennato in precedenza, la piattaforma di riconoscimento vocale di Windows viene usata per attivare tutte le esperienze vocali in Windows 10, ad esempio Cortana e dettatura.

Durante l'avvio, le funzionalità vengono raccolte usando IKeywordDetectorOemAdapter::GetCapabilities.

Successivamente, quando l'utente seleziona "Learn my voice", viene richiamato il flusso di training.

Questo diagramma descrive il processo di arming per il rilevamento delle parole chiave.

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. Una nuova proprietà dell'interfaccia dispositivo PnP è definita consentendo al driver di fornire espressioni statiche dei vincoli delle dimensioni del buffer al sistema operativo.

Dimensioni del buffer

Un driver opera sotto vari vincoli durante lo spostamento di 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 100ms e fino a 200ms.

Il driver esprime i vincoli di dimensione del buffer impostando la proprietà del dispositivo DEVPKEY_KsAudio_PacketSize_Constraints sull'interfaccia 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 il driver.

DEVPKEY_KsAudio_PacketSize_Constraints

Il valore della proprietà DEVPKEY_KsAudio_PacketSize_Constraints contiene una struttura KSAUDIO_PACKETSIZE_CONSTRAINTS 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 per qualsiasi modalità di elaborazione del segnale. Il driver imposta questa proprietà prima di chiamare PcRegisterSubdevice o abilitare 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 consigliata per lo stato di avanzamento della scrittura dal sistema operativo e per restituire una posizione di flusso precisa. 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 momento 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 impegnativo e deve essere eseguito in modo ponderato. I timestamp non devono semplicemente riflettere il momento in cui i campioni sono stati trasferiti a o dal sistema operativo al DSP.

• All'interno del DSP tenere traccia dei timestamp di esempio usando un orologio ASP interno.
• 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 semplici (ma meno precise) a piuttosto complesse o nuove (ma più precise).
• Fattore in eventuali ritardi costanti a causa di algoritmi di elaborazione del segnale o di trasporto hardware o di pipeline, a meno che questi ritardi non siano altrimenti conteggiati.

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 basato su pacchetti, incluso la funzione IMiniportWaveRTInputStream::GetReadPacket .

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

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

1. Dopo la transizione del flusso a KSSTATE_RUN, il driver imposta immediatamente l'evento di notifica del buffer perché ha già i 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 e 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 esempio nel pacchetto. Si noti che questo valore del contatore delle prestazioni potrebbe essere relativamente vecchio, a seconda della quantità di dati di acquisizione memorizzati nell'hardware o nel driver (all'esterno del buffer WaveRT).

   c. Se sono disponibili più dati 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 restituire 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. Passare a (2). Per i pin del rilevatore di parole chiave KSNODETYPE_AUDIO_KEYWORDDETECTOR, 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

Riattivazione vocale (WoV) consente all'utente di attivare ed eseguire query su un motore di riconoscimento vocale da uno schermo spento, uno stato di alimentazione inferiore, a uno stato di alimentazione completa, dicendo una determinata parola chiave, ad esempio "Ehi Cortana".

Questa funzionalità consente al dispositivo di essere sempre in ascolto della voce dell'utente mentre il dispositivo è in stato di bassa potenza, incluso quando lo schermo è spento e il dispositivo è inattivo. A tale scopo, viene usata una modalità di ascolto, che è una potenza inferiore rispetto all'utilizzo di potenza molto più elevato visto durante la normale registrazione del microfono. Il riconoscimento vocale a basso consumo consente a un utente di pronunciare semplicemente una frase chiave predefinita come "Ehi Cortana", seguita da una frase vocale concatenato come "when's my next appointment" per richiamare il parlato in modo senza mani. Questo funzionerà indipendentemente dal fatto che il dispositivo sia in uso o inattiva con lo schermo disattivato.

Lo stack audio è responsabile della comunicazione dei dati di riattivazione (ID voce, trigger di parole chiave, 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 della riattivazione standby moderna sull'origine ac-alimentazione e la riattivazione standby moderna sul test di base della voce sull'origine di alimentazione DC in HLK. Questi test verificano che il sistema disponga di un spotter con parole chiave hardware (HW-KWS), è in grado di immettere lo stato DRIPS (DeepEst Runtime Idle Platform State) ed è in grado di riattivare da Modern Standby al comando vocale con la latenza di ripresa del sistema inferiore o uguale a un secondo.