Ativação por Voz

Artigo
08/18/2023

Observação

Este tópico refere-se principalmente às nossas experiências de consumidor, que atualmente são entregues em Windows 10 (versão 1909 e anteriores) Para obter mais informações, consulte Fim do suporte para Cortana no Windows e no Teams.

A Cortana, a tecnologia de assistente pessoal, foi demonstrada pela primeira vez na Conferência de Desenvolvedores do Microsoft BUILD em 2013. A plataforma de fala do Windows é usada para alimentar todas as experiências de fala em Windows 10 como Cortana e Ditado. A ativação de voz é um recurso que permite que os usuários invoquem um mecanismo de reconhecimento de fala de vários estados de energia do dispositivo dizendo uma frase específica : "Ei Cortana". Para criar hardware que dê suporte à tecnologia de ativação de voz, examine as informações neste tópico.

Observação

A implementação da ativação de voz é um projeto significativo e é uma tarefa concluída pelos fornecedores de SoC. Os OEMs podem entrar em contato com o fornecedor do SoC para obter informações sobre a implementação de ativação de voz do SoC.

Experiência do usuário final da Cortana

Para entender a experiência de interação de voz disponível no Windows, examine estes tópicos.

Tópico	Descrição
O que é a Cortana?	Fornece visão geral e direção de uso para a Cortana

Introdução à Ativação de Voz "Ei Cortana" e "Aprenda minha voz"

Ativação de voz da Cortana

O recurso de VA (Ativação de Voz) "Ei Cortana" permite que os usuários envolvam rapidamente a experiência da Cortana fora do contexto ativo (ou seja, o que está atualmente na tela) usando sua voz. Os usuários geralmente querem ser capazes de acessar instantaneamente uma experiência sem precisar interagir fisicamente em um dispositivo. Para os usuários de telefone, isso pode ser devido a dirigir no carro e ter sua atenção e mãos envolvidas com a operação do veículo. Para um usuário do Xbox, isso pode ser devido a não querer encontrar e conectar um controlador. Para usuários de computador, isso pode ser devido ao acesso rápido a uma experiência sem precisar executar várias ações de mouse, toque e/ou teclado, por exemplo, um computador na cozinha.

A ativação de voz fornece sempre a entrada de fala de escuta por meio de frases-chave predefinidas ou "frases de ativação". Frases-chave podem ser proferidas por si mesmas ("Ei Cortana") como um comando em etapas ou seguidas por uma ação de fala, por exemplo, "Ei Cortana, onde é minha próxima reunião?", um comando encadeado.

O termo Detecção de Palavra-chave descreve a detecção do palavra-chave por hardware ou software.

A ativação da palavra-chave ocorre apenas quando apenas a cortana palavra-chave é dita, a Cortana inicia e reproduz o som EarCon para indicar que ela entrou no modo de escuta.

Um comando encadeado descreve a capacidade de emitir um comando imediatamente após o palavra-chave (como "Ei Cortana, ligar para João") e iniciar a Cortana (se ainda não tiver começado) e seguir o comando (iniciando uma chamada telefônica com João).

Este diagrama ilustra a ativação encadeada e palavra-chave apenas.

Diagrama mostrando a diferença entre a ativação encadeada e somente palavra-chave com buffer de áudio e sequência de tempo.

A Microsoft fornece um spotter palavra-chave padrão do sistema operacional (palavra-chave spotter de software) usado para garantir a qualidade das detecções de palavra-chave de hardware e para fornecer a experiência Hey Cortana nos casos em que a detecção de palavra-chave de hardware está ausente ou indisponível.

O recurso "Aprender minha voz"

O recurso "Aprenda minha voz" permite que o usuário treine a Cortana para reconhecer sua voz exclusiva. Isso é feito pelo usuário selecionando Saiba como digo "Ei Cortana" na tela de configurações da Cortana. Em seguida, o usuário repete seis frases cuidadosamente escolhidas que fornecem uma variedade suficiente de padrões fonéticos para identificar os atributos exclusivos da voz dos usuários.

Captura de tela das configurações de área de trabalho da Cortana para hardware palavra-chave spotter e ativar o recurso de voz.

Quando a ativação de voz é emparelhada com "Aprenda minha voz", os dois algoritmos trabalharão juntos para reduzir as ativações falsas. Isso é especialmente valioso para o cenário da sala de reunião, onde uma pessoa diz "Ei Cortana" em uma sala cheia de dispositivos. Esse recurso está disponível apenas para Windows 10 versão 1903 e anterior.

A ativação de voz é alimentada por um KWS (palavra-chave spotter) que reage se a frase-chave for detectada. Se o KWS for ativar o dispositivo de um estado de baixa potência, a solução será conhecida como WoV (Wake on Voice). Para obter mais informações, consulte Wake on Voice.

Glossário de termos

Esse glossário resume os termos relacionados à ativação de voz.

Termo	Exemplo/definição
Comando Staged	Exemplo: Hey Cortana <pause, wait for earcon> What's the weather? Às vezes, isso é chamado de "Comando de dois tiros" ou "Somente palavra-chave"
Comando encadeado	Exemplo: Ei Cortana, qual é o clima? Às vezes, isso é chamado de "comando one-shot"
Ativação por Voz	O cenário de fornecer palavra-chave detecção de uma frase-chave de ativação predefinida. Por exemplo, "Hey Cortana" é o cenário de Ativação do Microsoft Voice.
WoV	Wake-on-Voice – tecnologia que habilita a Ativação de Voz de uma tela desligada, estado de energia inferior, para uma tela em estado de energia total.
WoV do Modo de Espera Moderno	Wake-on-Voice de uma tela S0ix (Espera Moderna) fora do estado para uma tela em estado de energia total (S0).
Modern Standby	Infraestrutura ociosa do Windows Low Power – sucessora do CS (Connected Standby) no Windows 10. O primeiro estado de espera moderno é quando a tela está desativada. O estado de sono mais profundo é quando em DRIPS/Resiliência. Para obter mais informações, confira Espera Moderna
KWS	Spotter de palavra-chave – o algoritmo que fornece a detecção de "Ei Cortana"
SW KWS	Software palavra-chave spotter – uma implementação de KWS que é executada no host (CPU). Para "Hey Cortana", SW KWS é incluído como parte do Windows.
HW KWS	Spotter de palavra-chave descarregado por hardware – uma implementação de KWS que é executada descarregada no hardware.
Buffer de intermitência	Um buffer circular usado para armazenar dados pcm que podem ser 'estourados' no caso de uma detecção de KWS, para que todo o áudio que disparou uma detecção KWS seja incluído.
Adaptador OEM do Detector de Palavras-chave	Um shim no nível do driver que permite que o HW habilitado para WoV se comunique com o Windows e a pilha da Cortana.
Modelar	O arquivo de dados do modelo acústico usado pelo algoritmo KWS. O arquivo de dados é estático. Os modelos são localizados, um por localidade.

Integrando um spotter de palavra-chave de hardware

Para implementar um hardware palavra-chave fornecedores de soC HW KWS (spotter) devem concluir as tarefas a seguir.

Crie um detector de palavra-chave personalizado com base no exemplo SYSVAD descrito posteriormente neste tópico. Você implementará esses métodos em uma DLL COM, descrita em Interface do Adaptador OEM do Detector de Palavras-chave.
Implementar aprimoramentos WAVE RT descritos em Aprimoramentos do WAVERT.
Forneça entradas de arquivo INF para descrever as APOs personalizadas usadas para detecção de palavra-chave.
Examine as recomendações de hardware e as diretrizes de teste na Recomendação de Dispositivo de Áudio. Este tópico fornece diretrizes e recomendações para o design e o desenvolvimento de dispositivos de entrada de áudio destinados a uso com a Plataforma de Fala da Microsoft.
Suporte a comandos preparados e encadeados.
Suporte a "Hey Cortana" para cada uma das localidades da Cortana com suporte.
As APOs (Objetos de Processamento de Áudio) devem fornecer os seguintes efeitos:
- AEC
- AGC
- NS
Os efeitos para o modo de processamento de fala devem ser relatados pelo APO do MFX.
O APO pode executar a conversão de formato como MFX.
O APO deve gerar o seguinte formato:
- 16 kHz, mono, FLOAT.
Opcionalmente, crie apOs personalizados para aprimorar o processo de captura de áudio. Para obter mais informações, consulte Objetos de processamento de áudio do Windows.

Requisitos de WoV de palavra-chave de palavra-chave descarregados por hardware (HW KWS)

O HW KWS WoV tem suporte durante o estado de trabalho S0 e o estado de suspensão S0 também conhecido como Espera Moderna.
O HW KWS WoV não tem suporte do S3.

Requisitos de AEC para HW KWS

Para Windows versão 1709
- Para dar suporte ao HW KWS WoV para s0 estado de suspensão (modo de espera moderno) AEC não é necessário.
- O HW KWS WoV para o estado de trabalho S0 não tem suporte no Windows Versão 1709.
Para Windows Versão 1803
- Há suporte para o HW KWS WoV para o estado de trabalho S0.
- Para habilitar o HW KWS WoV para o estado de trabalho S0, o APO deve dar suporte à AEC.

Visão geral do código de exemplo

Há um código de exemplo para um driver de áudio que implementa a ativação de voz no GitHub como parte do exemplo do adaptador de áudio virtual SYSVAD. É recomendável usar esse código como ponto de partida. O código está disponível neste local.

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

Para obter mais informações sobre o driver de áudio de exemplo do SYSVAD, consulte Drivers de áudio de exemplo.

Informações do sistema de reconhecimento de palavra-chave

Suporte à pilha de áudio de ativação de voz

As interfaces externas da pilha de áudio para habilitar a Ativação de Voz servem como o pipeline de comunicação para a plataforma de fala e os drivers de áudio. As interfaces externas são divididas em três partes.

DDI (Interface do Driver de Dispositivo) do detector de palavras-chave. A interface do driver de dispositivo do detector de palavras-chave é responsável por configurar e armar o KWS (Keyword Spotter) do HWS. Ele também é usado pelo driver para notificar o sistema de um evento de detecção.
DLL do Adaptador OEM do Detector de Palavras-chave. Essa DLL implementa uma interface COM para adaptar os dados opacos específicos do driver para uso pelo sistema operacional para ajudar na detecção de palavra-chave.
Aprimoramentos de streaming do WaveRT. Os aprimoramentos permitem que o driver de áudio intermita o fluxo de dados de áudio armazenados em buffer da detecção de palavra-chave.

Propriedades do ponto de extremidade de áudio

A compilação do grafo do ponto de extremidade de áudio ocorre normalmente. O grafo está preparado para lidar com uma captura mais rápida do que em tempo real. Os carimbos de data/hora em buffers capturados permanecem verdadeiros. Especificamente, os carimbos de data/hora refletirão corretamente os dados que foram capturados no passado e armazenados em buffer e agora estão "estourando".

Teoria do streaming de áudio de bypass bluetooth

O driver expõe um filtro KS para seu dispositivo de captura como de costume. Esse filtro dá suporte a várias propriedades KS e a um evento KS para configurar, habilitar e sinalizar um evento de detecção. O filtro também inclui uma fábrica de pinos adicional identificada como um pino de palavra-chave spotter (KWS). Esse pin é usado para transmitir áudio do spotter palavra-chave.

As propriedades são:

Tipos de palavra-chave com suporte – KSPROPERTY_SOUNDDETECTOR_PATTERNS. Essa propriedade é definida pelo sistema operacional para configurar as palavras-chave a serem detectadas.
Lista de GUIDs de padrões de palavra-chave – KSPROPERTY_SOUNDDETECTOR_SUPPORTEDPATTERNS. Essa propriedade é usada para obter uma lista de GUIDs que identificam os tipos de padrões com suporte.
Armado - KSPROPERTY_SOUNDDETECTOR_ARMED. Essa propriedade de leitura/gravação é simplesmente booliana status indicando se o detector está armado. O sistema operacional define isso para envolver o detector de palavra-chave. O sistema operacional pode limpar isso para desengatar. O driver limpa isso automaticamente quando palavra-chave padrões são definidos e também depois que um palavra-chave é detectado. (O sistema operacional deve ser rearm.)
Resultado da correspondência – KSPROPERTY_SOUNDDETECTOR_MATCHRESULT. Essa propriedade de leitura contém os dados de resultado após a detecção.

O evento que é disparado quando um palavra-chave é detectado é um evento KSEVENT_SOUNDDETECTOR_MATCHDETECTED.

Sequência de operação

Inicialização do sistema

O sistema operacional lê os tipos de palavra-chave com suporte para verificar se ele tem palavras-chave nesse formato.
O sistema operacional registra para o detector status evento de alteração.
O sistema operacional define os padrões de palavra-chave.
O sistema operacional arma o detector.

Ao receber o evento KS

O motorista desarma o detector.
O sistema operacional lê o detector de palavra-chave status, analisa os dados retornados e determina qual padrão foi detectado.
O sistema operacional reorganiza o detector.

Operação interna de driver e hardware

Enquanto o detector está armado, o hardware pode estar capturando e armazenando dados de áudio em buffer contínuo em um pequeno buffer FIFO. (O tamanho desse buffer FIFO é determinado por requisitos fora deste documento, mas normalmente pode ser centenas de milissegundos para vários segundos.) O algoritmo de detecção opera no streaming de dados por meio desse buffer. O design do driver e do hardware é tal que, enquanto estiver armado, não há interação entre o driver e o hardware e nenhuma interrupção nos processadores de "aplicativo" até que um palavra-chave seja detectado. Isso permite que o sistema atinja um estado de energia mais baixo se não houver outra atividade.

Quando o hardware detecta um palavra-chave, ele gera uma interrupção. Enquanto aguarda o driver atender à interrupção, o hardware continua a capturar áudio no buffer, garantindo que nenhum dado após o palavra-chave seja perdido, dentro dos limites de buffer.

Carimbos de data/hora de palavra-chave

Depois de detectar um palavra-chave, todas as soluções de ativação de voz devem armazenar em buffer todos os palavra-chave falados, incluindo 250ms antes do início do palavra-chave. O driver de áudio deve fornecer carimbos de data/hora que identifiquem o início e o fim da frase-chave no fluxo.

Para dar suporte aos carimbos de data/hora de início/término palavra-chave, o software DSP pode precisar de eventos de carimbo de data/hora internamente com base em um relógio DSP. Depois que um palavra-chave é detectado, o software DSP interage com o driver para preparar um evento KS. O driver e o software DSP precisarão mapear os carimbos de data/hora DSP para um valor de contador de desempenho do Windows. O método de fazer isso é específico para o design de hardware. Uma solução possível é que o driver leia o contador de desempenho atual, consulte o carimbo de data/hora DSP atual, leia o contador de desempenho atual novamente e, em seguida, estime uma correlação entre o contador de desempenho e a hora do DSP. Em seguida, dada a correlação, o driver pode mapear os carimbos de data/hora do palavra-chave DSP para carimbos de data/hora do contador de desempenho do Windows.

Interface do adaptador OEM do detector de palavras-chave

O OEM fornece uma implementação de objeto COM que atua como um intermediário entre o sistema operacional e o driver, ajudando a calcular ou analisar os dados opacos que são gravados e lidos no driver de áudio por meio de KSPROPERTY_SOUNDDETECTOR_PATTERNS e KSPROPERTY_SOUNDDETECTOR_MATCHRESULT.

O CLSID do objeto COM é um GUID de tipo de padrão de detector retornado pelo KSPROPERTY_SOUNDDETECTOR_SUPPORTEDPATTERNS. O sistema operacional chama CoCreateInstance passando o GUID do tipo padrão para instanciar o objeto COM apropriado compatível com palavra-chave tipo de padrão e chama métodos na interface IKeywordDetectorOemAdapter do objeto.

Requisitos do Modelo de Threading COM

A implementação do OEM pode escolher qualquer um dos modelos de threading COM.

IKeywordDetectorOemAdapter

O design da interface tenta manter a implementação do objeto sem estado. Em outras palavras, a implementação não deve exigir que nenhum estado seja armazenado entre chamadas de método. Na verdade, as classes internas do C++ provavelmente não precisam de nenhuma variável de membro além daquelas necessárias para implementar um objeto COM em geral.

Métodos

Implemente os métodos a seguir.

KEYWORDID

A enumeração KEYWORDID identifica a frase texto/função de um palavra-chave e também é usada nos adaptadores do Serviço Biométrico do Windows. Para obter mais informações, confira Visão geral da estrutura biométrica – Componentes principais da plataforma

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

KEYWORDSELECTOR

O struct KEYWORDSELECTOR é um conjunto de IDs que seleciona exclusivamente uma palavra-chave e um idioma específicos.

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

Manipulando dados do modelo

Modelo independente do usuário estático – a DLL OEM normalmente incluiria alguns dados de modelo independente do usuário estático integrados à DLL ou em um arquivo de dados separado incluído com a DLL. O conjunto de IDs de palavra-chave com suporte retornados pela rotina GetCapabilities dependeria desses dados. Por exemplo, se a lista de IDs de palavra-chave com suporte retornadas por GetCapabilities incluir KwHeyCortana, os dados de modelo independente do usuário estático incluirão dados para "Hey Cortana" (ou sua tradução) para todos os idiomas com suporte.

Modelo dependente de usuário dinâmico – O IStream fornece um modelo de armazenamento de acesso aleatório. O sistema operacional passa um ponteiro de interface IStream para muitos dos métodos na interface IKeywordDetectorOemAdapter. O sistema operacional faz backup da implementação do IStream com armazenamento apropriado para até 1 MB de dados.

O conteúdo e a estrutura dos dados dentro desse armazenamento são definidos pelo OEM. A finalidade pretendida é o armazenamento persistente de dados de modelo dependentes do usuário computados ou recuperados pela DLL OEM.

O sistema operacional pode chamar os métodos de interface com um IStream vazio, especialmente se o usuário nunca treinou um palavra-chave. O sistema operacional cria um armazenamento IStream separado para cada usuário. Em outras palavras, um determinado IStream armazena dados de modelo para um e apenas um usuário.

O desenvolvedor de DLL OEM decide como gerenciar os dados independentes do usuário e dependentes do usuário. No entanto, ele nunca armazenará dados do usuário em qualquer lugar fora do IStream. Um possível design de DLL OEM alternaria internamente entre o acesso ao IStream e os dados independentes do usuário estático, dependendo dos parâmetros do método atual. Um design alternativo pode marcar o IStream no início de cada chamada de método e adicionar os dados independentes do usuário estático ao IStream se ainda não estiver presente, permitindo que o restante do método acesse apenas o IStream para todos os dados do modelo.

Treinamento e processamento de áudio de operação

Conforme descrito anteriormente, o fluxo de interface do usuário de treinamento resulta em frases fonéticas completas disponíveis no fluxo de áudio. Cada frase é passada individualmente para IKeywordDetectorOemAdapter::VerifyUserKeyword para verificar se ela contém o palavra-chave esperado e tem qualidade aceitável. Depois que todas as frases são coletadas e verificadas pela interface do usuário, todas elas são passadas em uma chamada para IKeywordDetectorOemAdapter::ComputeAndAddUserModelData.

O áudio é processado de maneira exclusiva para treinamento de ativação de voz. A tabela a seguir resume as diferenças entre o treinamento de ativação de voz e o uso regular de reconhecimento de voz.

	Treinamento de voz	Reconhecimento de Voz
Modo	Raw	Raw ou Speech
Pino	Normal	KWS
Formato de áudio	Float de 32 bits (Tipo = Áudio, Subtipo = IEEE_FLOAT, Taxa de Amostragem = 16 kHz, bits = 32)	Gerenciado pela pilha de áudio do sistema operacional
Microfone	Microfone 0	Todos os microfones na matriz ou mono

Visão geral do sistema de reconhecimento de palavras-chave

Este diagrama fornece uma visão geral do sistema de reconhecimento de palavra-chave.

Diagrama de palavra-chave sistema de reconhecimento, incluindo Cortana, runtime de fala e componentes do gerenciador de ativação de voz.

Diagramas de sequência de reconhecimento de palavra-chave

Nesses diagramas, o módulo de runtime de fala é mostrado como a "plataforma de fala". Conforme mencionado anteriormente, a plataforma de fala do Windows é usada para impulsionar todas as experiências de fala em Windows 10 como Cortana e ditado.

Durante a inicialização, os recursos são coletados usando IKeywordDetectorOemAdapter::GetCapabilities.

Diagrama de sequência de reconhecimento de palavra-chave durante a inicialização, mostrando o treinamento de EXPERIÊNCIA, plataforma de fala e detector de palavra-chave OEM.

Posteriormente, quando o usuário seleciona para "Aprender minha voz", o fluxo de treinamento é invocado.

Diagrama de sequência de reconhecimento de palavra-chave durante o processo

Este diagrama descreve o processo de arming para detecção de palavra-chave.

Diagrama de sequência de reconhecimento de palavra-chave durante o arming para detecção de palavra-chave, mostrando a plataforma de fala, o detector de palavra-chave OEM e o detector de unidade de áudio.

Aprimoramentos do WAVERT

As interfaces de miniporto são definidas para serem implementadas por drivers de miniporto WaveRT. Essas interfaces fornecem métodos para simplificar o driver de áudio, melhorar o desempenho e a confiabilidade do pipeline de áudio do sistema operacional ou dar suporte a novos cenários. Uma nova propriedade de interface do dispositivo PnP é definida, permitindo que o driver forneça expressões estáticas de suas restrições de tamanho de buffer para o sistema operacional.

Tamanhos de buffer

Um driver opera sob várias restrições ao mover dados de áudio entre o sistema operacional, o driver e o hardware. Essas restrições podem ser devido ao transporte de hardware físico que move dados entre memória e hardware e/ou devido aos módulos de processamento de sinal dentro do hardware ou DSP associado.

As soluções HW-KWS devem dar suporte a tamanhos de captura de áudio de pelo menos 100ms e até 200ms.

O driver expressa as restrições de tamanho do buffer definindo a propriedade do dispositivo DEVPKEY_KsAudio_PacketSize_Constraints na interface do dispositivo PnP KSCATEGORY_AUDIO do filtro KS que tem os pinos de streaming KS. Essa propriedade deve permanecer válida e estável enquanto a interface de filtro KS estiver habilitada. O sistema operacional pode ler esse valor a qualquer momento sem precisar abrir um identificador para o driver e chamar o driver.

DEVPKEY_KsAudio_PacketSize_Constraints

O valor da propriedade DEVPKEY_KsAudio_PacketSize_Constraints contém uma estrutura KSAUDIO_PACKETSIZE_CONSTRAINTS que descreve as restrições físicas de hardware (ou seja, devido à mecânica de transferência de dados do buffer WaveRT para o hardware de áudio). A estrutura inclui uma matriz de 0 ou mais estruturas KSAUDIO_PACKETSIZE_PROCESSINGMODE_CONSTRAINT que descrevem restrições específicas a qualquer modo de processamento de sinal. O driver define essa propriedade antes de chamar PcRegisterSubdevice ou habilitar sua interface de filtro KS para seus pinos de streaming.

IMiniportWaveRTInputStream

Um driver implementa essa interface para melhor coordenação do fluxo de dados de áudio do driver para o sistema operacional. Se essa interface estiver disponível em um fluxo de captura, o sistema operacional usará métodos nessa interface para acessar dados no buffer WaveRT. Para obter mais informações, consulte IMiniportWaveRTInputStream::GetReadPacket

IMiniportWaveRTOutputStream

Opcionalmente, um miniporto WaveRT implementa essa interface para ser avisado sobre o progresso da gravação do sistema operacional e retornar a posição precisa do fluxo. Para obter mais informações, consulte IMiniportWaveRTOutputStream::SetWritePacket, IMiniportWaveRTOutputStream::GetOutputStreamPresentationPosition e IMiniportWaveRTOutputStream::GetPacketCount.

Carimbos de data/hora do contador de desempenho

Várias das rotinas do driver retornam carimbos de data/hora do contador de desempenho do Windows refletindo o tempo em que os exemplos são capturados ou apresentados pelo dispositivo.

Em dispositivos que têm pipelines DSP complexos e processamento de sinal, calcular um carimbo de data/hora preciso pode ser desafiador e deve ser feito cuidadosamente. Os carimbos de data/hora não devem simplesmente refletir o tempo em que as amostras foram transferidas de ou para o sistema operacional para o DSP.

No DSP, acompanhe os carimbos de data/hora de exemplo usando algum relógio de parede DSP interno.
Entre o driver e o DSP, calcule uma correlação entre o contador de desempenho do Windows e o relógio de parede DSP. Os procedimentos para isso podem variar de muito simples (mas menos preciso) a bastante complexos ou novos (mas mais precisos).
Considere os atrasos constantes devido a algoritmos de processamento de sinal ou transportes de pipeline ou hardware, a menos que esses atrasos sejam contabilizados de outra forma.

Operação de leitura de intermitência

Esta seção descreve a interação do sistema operacional e do driver para leituras de intermitência. A leitura de intermitência pode ocorrer fora do cenário de ativação de voz, desde que o driver dê suporte ao modelo WaveRT de streaming baseado em pacotes, incluindo a função IMiniportWaveRTInputStream::GetReadPacket .

Dois cenários de leitura de exemplo de intermitência são discutidos. Em um cenário, se o miniporto der suporte a um pino com categoria de pino KSNODETYPE_AUDIO_KEYWORDDETECTOR, o driver começará a capturar e armazenar dados em buffer internamente quando um palavra-chave for detectado. Em outro cenário, o driver poderá opcionalmente armazenar dados em buffer interno fora do buffer WaveRT se o sistema operacional não estiver lendo dados rapidamente o suficiente chamando IMiniportWaveRTInputStream::GetReadPacket.

Para intermitência de dados que foram capturados antes da transição para KSSTATE_RUN, o driver deve reter informações precisas de carimbo de data/hora de exemplo junto com os dados de captura em buffer. Os carimbos de data/hora identificam o instantâneo de amostragem dos exemplos capturados.

Depois que o fluxo faz a transição para KSSTATE_RUN, o driver define imediatamente o evento de notificação de buffer porque ele já tem dados disponíveis.
Nesse evento, o sistema operacional chama GetReadPacket() para obter informações sobre os dados disponíveis.

a. O driver retorna o número do pacote dos dados capturados válidos (0 para o primeiro pacote após a transição de KSSTATE_STOP para KSSTATE_RUN), do qual o sistema operacional pode derivar a posição do pacote dentro do buffer WaveRT, bem como a posição do pacote em relação ao início do fluxo.

b. O driver também retorna o valor do contador de desempenho que corresponde ao instantâneo de amostragem do primeiro exemplo no pacote. Observe que esse valor do contador de desempenho pode ser relativamente antigo, dependendo de quantos dados de captura foram armazenados em buffer dentro do hardware ou driver (fora do buffer WaveRT).

c. Se houver mais dados em buffer não lidos disponíveis, o driver também estará disponível: i. Transfere imediatamente esses dados para o espaço disponível do buffer WaveRT (ou seja, espaço não usado pelo pacote retornado de GetReadPacket), retorna true para MoreData e define o evento de notificação de buffer antes de retornar dessa rotina. Ou, ii. Programa o hardware para intermitência do próximo pacote no espaço disponível do buffer WaveRT, retorna false para MoreData e, posteriormente, define o evento de buffer quando a transferência é concluída.
O sistema operacional lê dados do buffer WaveRT usando as informações retornadas por GetReadPacket().
O sistema operacional aguarda o próximo evento de notificação de buffer. A espera poderá terminar imediatamente se o driver definir a notificação de buffer na etapa (2c).
Se o driver não definiu imediatamente o evento na etapa (2c), o driver define o evento depois de transferir mais dados capturados para o buffer WaveRT e disponibilizá-lo para o sistema operacional ler
Vá para (2). Para KSNODETYPE_AUDIO_KEYWORDDETECTOR palavra-chave pinos de detector, os drivers devem alocar buffer de intermitência interno suficiente para pelo menos 5.000 m de dados de áudio. Se o sistema operacional não conseguir criar um fluxo no pino antes que o buffer transborde, o driver poderá encerrar a atividade de buffer interno e liberar recursos associados.

Wake on Voice

O WoV (Wake On Voice) permite que o usuário ative e consulte um mecanismo de reconhecimento de fala de uma tela desligada, estado de energia inferior, para uma tela ativada, estado de energia total dizendo uma determinada palavra-chave, como "Ei Cortana".

Esse recurso permite que o dispositivo esteja sempre escutando a voz do usuário enquanto o dispositivo estiver em um estado de baixa energia, inclusive quando a tela estiver desativada e o dispositivo estiver ocioso. Ele faz isso usando um modo de escuta, que é de menor potência quando comparado com o uso de energia muito maior visto durante a gravação normal do microfone. O reconhecimento de fala de baixo poder permite que um usuário simplesmente diga uma frase-chave predefinida como "Ei Cortana", seguida por uma frase de fala encadeada como "quando é meu próximo compromisso" para invocar a fala de maneira mãos livres. Isso funcionará independentemente de o dispositivo estiver em uso ou ocioso com a tela desativada.

A pilha de áudio é responsável por comunicar os dados de ativação (ID do locutor, gatilho palavra-chave, nível de confiança), bem como notificar os clientes interessados de que o palavra-chave foi detectado.

Validação em sistemas de espera modernos

O WoV de um estado ocioso do sistema pode ser validado em sistemas de espera modernos usando o Teste moderno de ativação em espera no Voice Basic na fonte de energia AC e o teste moderno de ativação em espera no voice basic na fonte de alimentação DC no HLK. Esses testes marcar que o sistema tem um HW-KWS (spotter palavra-chave de hardware), é capaz de entrar no DRIPS (Estado de Plataforma Ociosa de Runtime) mais profundo e é capaz de ativar o comando Modo de Espera Moderno em voz com latência de retomada do sistema menor ou igual a um segundo.