Ativação por voz

A Cortana, a plataforma de fala do Windows, potencializa todas as experiências de fala no Windows 10, como Cortana e ditado. A ativação por voz é um recurso que permite que os usuários invoquem um mecanismo de reconhecimento de fala a partir de vários estados de energia do dispositivo dizendo uma frase específica: "Olá Cortana". Para criar hardware que suporte a tecnologia de ativação por voz, revise as informações neste artigo.

Experiência do usuário final da Cortana

Para compreender a experiência de interação por voz disponível no Windows, consulte estes artigos.

Introdução à ativação por voz "Hey Cortana" e "Learn my voice"

Hey Cortana" Ativação por voz

O recurso "Hey Cortana" Voice Activation (VA) permite que os usuários envolvam rapidamente a experiência Cortana fora de seu 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 ter que interagir fisicamente ou tocar em um dispositivo. Os usuários de telefone podem estar dirigindo no carro e tendo sua atenção e mãos envolvidas com a operação do veículo. Um utilizador da Xbox poderá não querer encontrar e conectar um comando. Os usuários de PC podem querer acesso rápido a uma experiência sem ter que executar várias ações de mouse, toque ou teclado. Por exemplo, um computador na cozinha a ser usado enquanto alguém cozinha.

A ativação por voz permite ouvir sempre a entrada de voz através de frases-chave ou frases de ativação predefinidas. As frases-chave podem ser proferidas por si mesmas ("Hey Cortana") como um comando preparado, ou seguidas por uma ação de fala, por exemplo, "Hey Cortana, onde é a minha próxima reunião?", um comando encadeado.

O termo Deteção de palavras-chave descreve a deteção da palavra-chave por hardware ou software.

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

Um comando encadeado descreve a capacidade de emitir um comando imediatamente após a palavra-chave (como "Hey Cortana, call John") e fazer com que a Cortana inicie (se ainda não tiver começado) e siga o comando (iniciando uma chamada telefônica com John).

Este diagrama ilustra a ativação encadeada e somente com palavras-chave.

Diagrama que mostra a diferença entre ativação encadeada e ativação apenas por palavra-chave, com buffer de áudio e sequência temporal.

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

A funcionalidade "Aprender a minha voz"

O recurso "Aprenda minha voz" permite que o usuário treine a Cortana para reconhecer sua voz exclusiva. Isso é feito pelo utilizador selecionando Aprender como eu digo "Hey 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 do usuário.

Captura de ecrã das definições da Cortana no ambiente de trabalho para a deteção de palavras-chave de hardware e a funcionalidade de ativação por voz.

Quando a ativação por voz é emparelhada com "Aprenda minha voz", os dois algoritmos trabalham juntos para reduzir ativações falsas. Isso é especialmente valioso para o cenário de sala de reunião, onde uma pessoa diz "Hey Cortana" em uma sala cheia de dispositivos. Esta funcionalidade está disponível apenas para o Windows 10 versão 1903 e anteriores.

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

Glossário de Termos

Este glossário resume os termos relacionados com a ativação por voz.

Integrando um detetor de palavras-chave de hardware

Para implementar um spotter de palavras-chave de hardware (HW KWS), conclua as tarefas a seguir.

• Crie um detetor de palavras-chave personalizado com base no exemplo SYSVAD descrito posteriormente neste artigo. Você implementará esses métodos em uma DLL COM, descrita em Interface do adaptador OEM do detetor de palavras-chave.
• Implemente as melhorias do WAVE RT descritas em WAVERT Enhancements.
• Forneça entradas de arquivo INF para descrever quaisquer APOs personalizados usados para deteção de palavras-chave.
  • PKEY_FX_KeywordDetector_StreamEffectClsid
  • #B0 PKEY_FX_KeywordDetector_ModeEffectClsid #C1
  • #B0 PKEY_FX_KeywordDetector_EndpointEffectClsid #C1
  • #B0 PKEY_SFX_KeywordDetector_ProcessingModes_Supported_For_Streaming #C1
  • PKEY_MFX_KeywordDetector_ProcessingModes_Supported_For_Streaming
  • #B0 PKEY_EFX_KeywordDetector_ProcessingModes_Supported_For_Streaming #C1
• Analise as recomendações de hardware e as diretrizes de teste em Recomendação de Dispositivo de Áudio. Este artigo fornece orientações e recomendações para o design e desenvolvimento de dispositivos de entrada de áudio destinados ao uso com a plataforma de fala da Microsoft.
• Suporta comandos faseados e encadeados.
• Suporte "Hey Cortana" para cada uma das localidades Cortana suportadas.
• Os APOs (Audio Processing Objects) devem fornecer os seguintes efeitos:
  • AEC
  • AGC
  • NS
• Os efeitos para o modo de processamento de fala devem ser relatados pelo MFX APO.
• O APO pode executar a conversão de formato para MFX.
• O APO deve produzir o seguinte formato:
  • 16 kHz, mono, FLOAT.
• Opcionalmente, projete quaisquer APOs personalizados para melhorar o processo de captura de áudio. Para obter mais informações, consulte Objetos de processamento de áudio do Windows.

Requisitos do WoV do localizador de palavras-chave descarregado por hardware (HW KWS)

• O HW KWS WoV é suportado durante o estado de trabalho S0 e o estado de suspensão S0, também conhecido como modo de espera moderno.
• HW KWS WoV não é suportado a partir do S3.

Requisitos AEC para HW KWS

• Para Windows versão 1709

  • Para suportar o HW KWS WoV no estado de suspensão S0 (Modern Standby), o AEC não é necessário.
  • O estado de trabalho HW KWS WoV for S0 não é suportado no Windows Versão 1709.

• Para Windows versão 1803

  • HW KWS WoV para o estado de trabalho S0 é suportado.
  • Para que o HW KWS WoV funcione no estado de trabalho S0, é necessário que o APO 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 por voz no GitHub como parte do exemplo de adaptador de áudio virtual SYSVAD. Recomenda-se usar este 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 SYSVAD, consulte Drivers de áudio de exemplo.

Informações do Sistema de Reconhecimento de Palavras-Chave

Suporte de Stack de Áudio de Ativação por Voz

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

• Detetor de palavras-chave Device Driver Interface (DDI). O detetor de palavras-chave Device Driver Interface é responsável por configurar e armar o HW Keyword Spotter (KWS). Ele também é usado pelo motorista para notificar o sistema de um evento de deteção.
• Detetor de palavras-chave OEM Adapter DLL. Esta DLL implementa uma interface COM para adaptar os dados opacos específicos do driver para uso pelo sistema operacional para ajudar na deteção de palavras-chave.
• Melhorias de transmissão do WaveRT. As melhorias permitem que o driver de áudio realize a transmissão acelerada dos dados de áudio em buffer a partir da deteção de palavra-chave.

Propriedades do ponto de extremidade de áudio

A construção do gráfico de ponto final de áudio ocorre normalmente. O gráfico está preparado para lidar mais rápido do que a captura em tempo real. Os carimbos de data/hora nos buffers capturados permanecem verdadeiros. Especificamente, os carimbos de data/hora refletem corretamente os dados que foram capturados no passado e armazenados em buffer, e agora estão intermitindo.

Teoria do desvio de fluxo de áudio Bluetooth

O driver expõe um filtro KS para seu dispositivo de captura como de costume. Este filtro suporta várias propriedades KS e um evento KS para configurar, ativar e sinalizar um evento de deteção. O filtro também inclui outro componente de pinos identificado como um pino detector de palavras-chave (KWS). Este pino é usado para transmitir áudio do detetor de palavras-chave.

Os imóveis são:

• Tipos de palavras-chave suportados - KSPROPERTY_SOUNDDETECTOR_PATTERNS. O sistema operacional define essa propriedade para configurar as palavras-chave a serem detetadas.
• Lista de padrões de palavras-chave GUIDs - KSPROPERTY_SOUNDDETECTOR_SUPPORTEDPATTERNS. Esta propriedade é usada para obter uma lista de GUIDs que identificam os tipos de padrões suportados.
• Armado - KSPROPERTY_SOUNDDETECTOR_ARMED. Esta propriedade de leitura/gravação é um valor booleano que indica ou não se o detetor está armado. O sistema operacional define isso para ativar o detetor de palavras-chave. O sistema operacional pode limpar isso para desativar. O driver limpa isso automaticamente quando padrões de palavras-chave são definidos e também depois que uma palavra-chave é detetada. (O SO deve rearmar.)
• Resultado de correspondência - KSPROPERTY_SOUNDDETECTOR_MATCHRESULT. Esta propriedade de leitura contém os dados do resultado após a deteção ter ocorrido.

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

Sequência de Operação

Inicialização do sistema

1. O SO lê os tipos de palavras-chave suportados para verificar se tem palavras-chave nesse formato.
2. O sistema operativo inscreve-se no evento de alteração de estado do detetor.
3. O SO define os padrões de palavras-chave.
4. O sistema operacional arma o detetor.

Ao receber o evento KS

1. O motorista desarma o detetor.
2. O sistema operacional lê o status do detetor de palavras-chave, analisa os dados retornados e determina qual padrão foi detetado.
3. O sistema operacional rearma o detetor.

Driver interno e operação de hardware

Enquanto o detetor está armado, o hardware pode capturar e armazenar continuamente dados de áudio num pequeno buffer FIFO. (O tamanho desse buffer FIFO é determinado por requisitos fora deste documento, mas normalmente pode ser de centenas de milissegundos a vários segundos.) O algoritmo de deteção opera no fluxo de dados através deste buffer. O design do driver e do hardware são tais que, enquanto armados, não há interação entre o driver e o hardware e nenhuma interrupção para os processadores de "aplicativo" até que uma palavra-chave seja detetada. Isso permite que o sistema atinja um estado de energia mais baixo se não houver outra atividade.

Quando o hardware deteta uma palavra-chave, gera uma interrupção. Enquanto aguarda que o driver faça o serviço de interrupção, o hardware continua a capturar áudio no buffer, garantindo que nenhum dado após a palavra-chave seja perdida, dentro dos limites de buffer.

Carimbos de data/hora de palavras-chave

Depois de detetar uma palavra-chave, todas as soluções de ativação por voz devem armazenar em buffer todas as palavras-chave faladas, incluindo 250ms antes do início da palavra-chave. O driver de áudio deve fornecer timestamps identificando o início e o fim da frase-chave no fluxo de dados.

Para suportar os carimbos de data/hora de início e fim das palavras-chave, o software DSP pode precisar criar internamente carimbos de eventos baseados num relógio DSP. Uma vez que uma palavra-chave é detetada, o software DSP interage com o driver para preparar um evento KS. O driver e o software DSP precisam mapear os timestamps do DSP para um valor do 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 do DSP atual, leia o contador de desempenho atual novamente e, em seguida, estime uma correlação entre o contador de desempenho e o tempo do DSP. Em seguida, dada a correlação, o driver pode mapear os timestamps DSP por palavra-chave para os timestamps do contador de desempenho do Windows.

Interface do adaptador OEM do detetor de palavras-chave

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

O CLSID do objeto COM é um GUID de tipo de padrão detetor retornado pelo KSPROPERTY_SOUNDDETECTOR_SUPPORTEDPATTERNS. O sistema operacional chama CoCreateInstance passando o GUID do tipo de padrão para instanciar o objeto COM apropriado que é compatível com o tipo de padrão de palavra-chave 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 C++ internas provavelmente não precisam de nenhuma variável membro além daquelas necessárias para implementar um objeto COM em geral.

Metodologia

Implemente os seguintes métodos.

• IKeywordDetectorOemAdapter::BuildArmingPatternData
• #B0 #A1 IKeywordDetectorOemAdapter::ComputeAndAddUserModelData #A2 #C3
• IKeywordDetectorOemAdapter::GetCapabilities
• IKeywordDetectorOemAdapter::ParseDetectionResultData
• #B0 #A1 IKeywordDetectorOemAdapter::VerifyUserKeyword #A2 #C3

KEYWORDID

A KEYWORDID enum identifica o texto/frase ou função de uma palavra-chave e também é usada nos adaptadores do Serviço Biométrico do Windows. Para obter mais informações, consulte Visão Geral do Framework Biométrico - Componentes Principais da Plataforma

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

SELETOR DE PALAVRAS-CHAVE

A estrutura KEYWORDSELECTOR é um conjunto de IDs que selecionam exclusivamente uma palavra-chave e um idioma.

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

Manipulando dados do modelo

Modelo estático independente do utilizador - A DLL OEM normalmente incluiria alguns dados de modelos estáticos independentes do utilizador integrados na DLL ou num ficheiro de dados separado incluído com a DLL. O conjunto de IDs de palavra-chave suportadas retornado pela rotina GetCapabilities dependeria desses dados. Por exemplo, se a lista de IDs de palavra-chave suportados retornada por GetCapabilities incluir KwHeyCortana, os dados do modelo independente do usuário estático incluirão dados para "Hey Cortana" (ou sua tradução) para todos os idiomas suportados.

Modelo dinâmico dependente do usuário - 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 apoia a implementação IStream com armazenamento apropriado para até 1MB de dados.

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

O SO pode chamar os métodos de interface com um IStream vazio, particularmente se o usuário nunca treinou uma palavra-chave específica. O sistema operacional cria um armazenamento IStream separado para cada usuário. Em outras palavras, um determinado IStream armazena dados de modelo para um único utilizador.

O desenvolvedor da OEM DLL decide como gerir os dados independentes do utilizador e dependentes do utilizador. No entanto, nunca armazenará dados do utilizador fora do IStream. Um possível design de DLL OEM alternaria internamente entre acessar o IStream e os dados estáticos independentes do usuário, dependendo dos parâmetros do método atual. Um design alternativo pode verificar o IStream no início de cada chamada de método e adicionar os dados estáticos independentes do usuário ao IStream se ainda não estiverem presentes, permitindo que o restante do método acesse apenas o IStream para todos os dados do modelo.

Formação e Operação de Processamento de Áudio

Como descrito anteriormente, o fluxo da interface do usuário de treinamento resulta em frases completas e foneticamente ricas disponíveis no fluxo de áudio. Cada sentença é passada individualmente para IKeywordDetectorOemAdapter::VerifyUserKeyword para verificar se contém a palavra-chave esperada e tem qualidade aceitável. Depois que todas as frases são reunidas e verificadas pela interface do usuário, todas elas são passadas em uma chamada para IKeywordDetectorOemAdapter::ComputeAndAddUserModelData.

O áudio é processado de forma única para o treino de ativação por 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.

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

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

Diagramas de sequência de reconhecimento de palavras-chave

Nesses diagramas, o módulo de tempo de execução de fala é mostrado como a plataforma de fala. Como mencionado anteriormente, a plataforma de fala do Windows é usada para potencializar todas as experiências de fala no Windows 10, como Cortana e ditado.

Durante a inicialização, as capacidades são recolhidas usando IKeywordDetectorOemAdapter::GetCapabilities.

Diagrama de sequência para reconhecimento de palavras-chave durante a inicialização, mostrando UX de treino, plataforma de reconhecimento de fala e detetor de palavras-chave do fabricante OEM.

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

Diagrama de sequência do reconhecimento de palavras-chave durante o processo 'Aprender a minha voz', mostrando a experiência do utilizador no treino, a plataforma de reconhecimento de voz e o detetor de palavras-chave OEM.

Este diagrama descreve o processo de configuração para deteção de palavras-chave.

Diagrama de sequência do reconhecimento de palavras-chave durante o processo de armamento para deteção de palavras-chave, mostrando a plataforma de reconhecimento de fala, o detector de palavras-chave OEM e o detector de unidade de áudio.

Aprimoramentos do WAVERT

As interfaces de miniporta são definidas para serem implementadas pelos drivers de miniporta 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 oferecer suporte a novos cenários. Uma nova propriedade de interface de 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 a memória e o hardware e/ou devido aos módulos de processamento de sinal dentro do hardware ou DSP associado.

HW-KWS soluções devem suportar 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 DEVPKEY_KsAudio_PacketSize_Constraints device na interface de dispositivo PnP KSCATEGORY_AUDIO do filtro KS que tem os pinos de streaming KS. Esta propriedade deve permanecer válida e estável enquanto a interface do filtro KS estiver ativada. O sistema operativo pode ler este valor a qualquer momento sem ter que abrir um identificador para o controlador e chamar o controlador.

DEVPKEY_KsAudio_PacketSize_Constraints

O valor da propriedade DEVPKEY_KsAudio_PacketSize_Constraints contém uma estrutura KSAUDIO_PACKETSIZE_CONSTRAINTS que descreve as restrições de hardware físico (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 descrevendo restrições específicas para qualquer modo de processamento de sinal. O driver define esta propriedade antes de chamar PcRegisterSubdevice ou de ativar a sua interface de filtro KS para os seus pinos de transmissão.

IMiniportWaveRTInputStream

Um driver implementa essa interface para uma 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

Uma miniporta WaveRT pode opcionalmente implementar esta interface para ser notificada sobre o progresso da escrita pelo SO e para devolver a posição precisa da transmissão. Para obter mais informações, consulte IMiniportWaveRTOutputStream::SetWritePacket, IMiniportWaveRTOutputStream::GetOutputStreamPresentationPosition e IMiniportWaveRTOutputStream::GetPacketCount.

Carimbos de data e hora dos contadores de desempenho

Várias das rotinas de driver retornam carimbos de data/hora do contador de desempenho do Windows, que refletem o momento em que as amostras são capturadas ou apresentadas pelo dispositivo.

Em dispositivos que têm pipelines DSP complexos e processamento de sinal, calcular um timestamp preciso pode ser desafiador e deve ser considerado cuidadosamente. Os timestamps não devem refletir a hora em que as amostras foram transferidas entre o sistema operativo e o processador de sinais digitais.

• Dentro do DSP, rastreie os carimbos temporais de amostra usando um relógio interno do DSP.
• 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 o efeito podem variar de simples (mas menos precisos) a bastante complexos ou novos (mas mais precisos).
• Leve em conta quaisquer atrasos constantes devido a algoritmos de processamento de sinal, pipeline ou transporte de hardware, a menos que esses atrasos sejam contabilizados de outra forma.

Operação de leitura rápida

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

Dois cenários de leitura de exemplo de burst são discutidos. Em um cenário, se a miniporta suportar um pino da categoria de pino KSNODETYPE_AUDIO_KEYWORDDETECTOR, o driver começará a capturar e bufferizar dados internamente quando for detetada uma palavra-chave. Em outro cenário, o driver pode direcionar dados para um buffer interno fora do buffer WaveRT caso o sistema operativo não esteja a ler os dados com rapidez suficiente ao invocar IMiniportWaveRTInputStream::GetReadPacket.

Para divulgar dados que foram capturados antes da transição para KSSTATE_RUN, o driver deve reter informações precisas de timestamp de amostra juntamente com os dados de captura em buffer. Os carimbos de data/hora identificam o instante de amostragem das amostras capturadas.

1. Depois que o fluxo transita para KSSTATE_RUN, o driver define imediatamente o evento de notificação de buffer porque já tem dados disponíveis.

2. Nesse evento, o sistema operacional chama GetReadPacket() para obter informações sobre os dados disponíveis.

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

   2. O driver também retorna o valor do contador de desempenho que corresponde ao instante de amostragem da primeira amostra no pacote. Esse valor do contador de desempenho pode ser relativamente antigo, dependendo da quantidade de dados de captura que foram armazenados em buffer no hardware ou driver (fora do buffer WaveRT).

   3. Se houver mais dados bufferizados não lidos disponíveis, o driver deve proceder de uma das seguintes maneiras:

      1. 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,
      2. Programa o hardware para estourar o próximo pacote no espaço disponível do buffer WaveRT, retorna false para MoreData e, posteriormente, define o evento buffer quando a transferência for concluída.

3. O sistema operacional lê dados do buffer WaveRT usando as informações retornadas por GetReadPacket().

4. O SO aguarda o próximo evento de notificação de buffer. A espera pode ser concluída imediatamente se o driver configurar a notificação de buffer no passo (2c).

5. Se o driver não definiu imediatamente o evento na etapa (2c), o driver define o evento depois que ele transfere mais dados capturados para o buffer WaveRT e o disponibiliza para o sistema operacional ler

6. Vá para (2). Para pinos de detetor de palavras-chave KSNODETYPE_AUDIO_KEYWORDDETECTOR, os drivers devem alocar buffer interno de burst suficiente para 5000 ms de dados de áudio, no mínimo. Se o sistema operacional falhar em criar um fluxo no pino antes que o buffer transborde; o driver poderá encerrar a atividade de armazenamento em buffer interno e liberar os recursos associados.

Despertar na voz

O Wake On Voice (WoV) permite que o usuário ative e consulte um mecanismo de reconhecimento de fala de uma tela desligada, estado de energia mais baixa, para uma tela ligada, estado de potência total dizendo uma determinada palavra-chave, como "Hey Cortana".

Este recurso permite que o dispositivo esteja sempre ouvindo a voz do usuário enquanto o dispositivo está em um estado de baixa energia, incluindo quando a tela está desligada e o dispositivo está ocioso. Ele faz isso usando um modo de escuta, que consome de potência mais baixa quando comparado com o maior uso de energia visto durante a gravação normal do microfone. O reconhecimento de fala de baixa potência permite que um usuário diga uma frase-chave predefinida como "Hey Cortana", seguida por uma frase de fala encadeada como "quando é o meu próximo compromisso" para iniciar a fala de forma mãos-livres. Isso funciona independentemente de o dispositivo estar em uso ou ocioso com a tela desligada.

O stack de áudio é responsável por transmitir os dados de ativação (ID do alto-falante, gatilho de palavra-chave, nível de confiança) e notificar os clientes interessados de que a palavra-chave foi detetada.

Validação em sistemas de espera modernos

O WoV a partir de um estado ocioso do sistema pode ser validado em Modern Standby sistemas usando o Modern Standby Wake on Voice Basic Test na fonte de alimentação CA e o Modern Standby Wake on Voice Basic Test na fonte de alimentação DC no HLK. Esses testes verificam se o sistema tem um detetor de palavras-chave de hardware (HW-KWS), é capaz de entrar no estado mais profundo de inatividade em tempo de execução da plataforma (DRIPS) e é capaz de despertar do "Modern Standby" com comando de voz, com latência de retomada do sistema menor ou igual a um segundo.