Partilhar via

Ativação por Voz

  • Artigo

Observação

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

Cortana, a tecnologia de assistente pessoal, foi demonstrada pela primeira vez na Microsoft BUILD Developer Conference em 2013. A plataforma de fala do Windows é usada para potencializar todas as experiências de fala no Windows 10, como Cortana e Ditado. A ativação por voz é um recurso que permite aos usuários invocar um mecanismo de reconhecimento de fala de vários estados de energia do dispositivo dizendo uma frase específica – "Ei, Cortana". Para criar um hardware que ofereça suporte à tecnologia de ativação por voz, revise as informações neste tópico.

Observação

A implementação da ativação de voz é um projeto significativo e é realizada pelos fornecedores de SoC. Os OEMs podem entrar em contato com seu fornecedor de SoC para obter informações sobre a implementação de ativação de voz dos SoCs.

Experiência do usuário final da Cortana

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

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

Introdução à ativação de voz "Ei, Cortana" e "Aprenda minha voz"

Ativação de voz "Ei, Cortana"

O recurso Ativação de voz "Ei, Cortana" (VA) permite que os usuários ativem rapidamente a experiência da Cortana fora do seu contexto ativo (ou seja, o que está atualmente na tela) usando sua voz. Os usuários geralmente querem poder acessar instantaneamente uma experiência sem ter que interagir fisicamente com um dispositivo. Os usuários de smartphone podem querer usar o recurso ao dirigir o carro mantendo a atenção e as mãos voltadas à operação do veículo. Um usuário do Xbox podem usá-lo para encontrar e conectar um controle. Usuários de PC podem querer ter acesso rápido a uma experiência sem ter que realizar várias ações de mouse, toque e/ou teclado, por exemplo, um computador na cozinha.

A ativação por voz permite comandos de fala por meio de frases predefinidas ou de ativação. As frases-chave podem ser autorreferenciadas ("Ei, Cortana") como um comando por etapas ou seguidas por uma ação, por exemplo, "Ei, Cortana, onde será minha próxima reunião?", um comando encadeado.

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

A ativação somente por palavra-chave ocorre quando apenas a palavra-chave Cortana é dita. Então, Cortana inicia e reproduz o som do 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 "Ei, Cortana, ligar para 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 por palavra-chave.

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

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

O recurso "Aprenda minha voz"

O recurso "Aprenda minha voz" permite que o usuário treine a Cortana para reconhecer sua voz. Isso é feito quando o usuário seleciona Aprender como eu digo "Olá Cortana" na tela de configurações da Cortana. O usuário então repete seis frases cuidadosamente escolhidas que fornecem uma variedade suficiente de padrões fonéticos para identificar os atributos únicos da voz do usuário.

Captura de tela das configurações da área de trabalho da Cortana para o identificador de palavras-chave de hardware e o recurso de ativação por voz.

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

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

Glossário de Termos

Este glossário resume termos relacionados à ativação por voz.

Termo Definição/exemplo
Comando por etapas Exemplo: Ei, Cortana <pausar, aguardar earcon> Como está o tempo? Isso às vezes é chamado de "Comando de dois disparos" ou "Somente por palavra-chave"
Comando encadeado Exemplo: Ei, Cortana. Como está o tempo? Isso às vezes é chamado de "Comando de disparo único"
Ativação por Voz O cenário de fornecer detecção por palavra-chave de uma frase-chave de ativação predefinida. Por exemplo, "Ei, Cortana" é o cenário de ativação do Microsoft Voice.
WoV Wake-on-Voice – Tecnologia que permite a Ativação por Voz de uma tela desligada, em estado de economia de energia, para uma tela em estado de potência total.
WoV a partir do modo de espera moderno Wake-on-Voice a partir de uma tela no modo de espera moderno (S0ix) para o estado de tela em potência total (S0).
Modern Standby Infraestrutura de estado ocioso de economia de energia do Windows – sucessora do modo de espera conectado (CS) no Windows 10. O primeiro estado de espera moderno é quando a tela está desligada. O estado de suspensão mais profundo é quando o computador está em DRIPS/Resiliência. Para obter mais informações, consulte Modo de espera moderno.
KWS Identificador de palavras-chave – o algoritmo que fornece a detecção de "Ei, Cortana"
SW KWS Identificador de palavra-chave do hardware – uma implementação do KWS que é executada no host (CPU). Para "Ei, Cortana", o SW KWS está incluído como parte do Windows.
HW KWS Identificador de palavra-chave descarregado por hardware – uma implementação do KWS que é executada descarregada no hardware.
Buffer de intermitência Um buffer circular usado para armazenar dados PCM que podem ser ativados no caso de uma detecção por KWS, para que todo o áudio que acionou uma detecção seja incluído.
Adaptador OEM do detector por palavras-chave Uma correção 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 de KWS. O arquivo de dados é estático. Os modelos são localizados, um por localidade.

Integrar um identificador de palavra-chave do hardware

Para implementar um identificador de palavra-chave de hardware (HW KWS), os fornecedores de SoC devem realizar as tarefas a seguir.

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

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

Requisitos AEC para HW KWS

  • Para Windows, versão 1709

    • Para suportar WoV do HW KWS para estado de suspensão S0 (Modo de espera moderno), o AEC não é necessário.
    • O WoV do HW KWS para o estado de trabalho S0 não é suportado no Windows, versão 1709.

  • Para Windows, versão 1803

    • O WoV do HW KWS é suportado para o estado de trabalho S0.
    • Para habilitar o WoV do HW KWS para o estado de trabalho S0, o APO deve oferecer suporte ao AEC.

Visão geral do código de exemplo

Há código de exemplo para um driver de áudio que implementa a ativação de voz no GitHub como parte da amostra de adaptador de áudio virtual SYSVAD. Recomenda-se 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 amostra do SYSVAD, consulte Drivers de áudio de amostra.

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

Suporte à pilha de áudio de ativação de 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 são divididas em três partes.

  • Interface de driver de dispositivo (DDI) do detector de palavras-chave. O Interface de driver de dispositivo do detector de palavras-chave é responsável por configurar e ativar o Identificador de palavras-chave de HW (KWS). Ele também é usado pelo driver para notificar o sistema de um evento de detecção.
  • Adaptador DLL do OEM do detector de palavras-chave. Esta 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 palavras-chave.
  • Aprimoramentos de streaming do WaveRT. Os aprimoramentos permitem que o driver de áudio transmita os dados de áudio em buffer a partir da detecção de palavra-chave.

Propriedades do ponto de extremidade de áudio

A construção do gráfico de ponto de extremidade de áudio ocorre normalmente. O gráfico está preparado para lidar com a captura mais rápida do que em tempo real. Os carimbos de data/hora nos 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 em bursting.

Teoria do streaming de áudio de bypass Bluetooth

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

As propriedades são:

  • Tipos de palavras-chave suportados – KSPROPERTY_SOUNDDETECTOR_PATTERNS. Essa propriedade é definida pelo sistema operacional para configurar as palavras-chave a serem detectadas.
  • Lista de padrões de palavras-chave GUIDs – KSPROPERTY_SOUNDDETECTOR_SUPPORTEDPATTERNS. Essa propriedade é usada para obter uma lista de GUIDs que identificam os tipos de padrões com suporte.
  • Ativado – KSPROPERTY_SOUNDDETECTOR_ARMED. Essa propriedade de leitura/gravação é um status booleano que indica se o detector está ativado. O sistema operacional define isso para ativar o detector de palavras-chave. O sistema operacional pode limpar esse comando para desativar. O driver limpa esse comando automaticamente quando os padrões de palavra-chave são definidos e também depois que uma palavra-chave é detectada. (O sistema operacional deve reativar.)
  • Resultado de correspondência – KSPROPERTY_SOUNDDETECTOR_MATCHRESULT. Essa propriedade de leitura contém os dados de resultado após a detecção.

O evento que é acionado quando uma palavra-chave é detectada é um evento KSEVENT_SOUNDDETECTOR_MATCHDETECTED.

Sequência de operações

Inicialização do sistema

  1. O sistema operacional lê os tipos de palavras-chave suportados para verificar se tem palavras-chave nesse formato.
  2. O sistema operacional registra o evento de alteração de status do detector.
  3. O sistema operacional define os padrões de palavra-chave.
  4. O sistema operacional aciona o detector.

Ao receber o evento KS

  1. O driver desativa o detector.
  2. O sistema operacional lê o status do detector de palavras-chave, analisa os dados retornados e determina qual padrão foi detectado.
  3. O sistema operacional aciona novamente o detector.

Driver interno e operação de hardware

Enquanto o detector está acionado, o hardware pode estar continuamente capturando e armazenando dados de áudio em buffer em um 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 detecção opera no fluxo de dados por meio desse buffer. O design do driver e do hardware permite que, durante o acionamento, não haja interação entre o driver e o hardware e nenhuma interrupção para os processadores de "aplicativo" até que uma palavra-chave seja detectada. Isso permite que o sistema atinja um estado de menor potência se não houver outra atividade.

Quando o hardware detecta uma palavra-chave, ele gera uma interrupção. Enquanto aguarda que o driver atenda a interrupção, o hardware continua a capturar áudio no buffer, garantindo que nenhum dado depois da palavra-chave seja perdido, dentro dos limites de buffer.

Carimbos de data/hora de palavra-chave

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

Para suportar os carimbos de data/hora de início/fim da palavra-chave, o software DSP pode precisar de eventos de carimbo de data/hora internos com base em um relógio DSP. Uma vez que uma palavra-chave é detectada, 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 o tempo do DSP. Em seguida, dada a correlação, o driver pode mapear os carimbos de data/hora DSP da palavra-chave 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 do tipo padrão de detector 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 monitoração de estado. Em outras palavras, a implementação deve exigir que nenhum estado seja armazenado entre as chamadas de método. Na verdade, as classes C++ internas 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 o texto/função da frase 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 da estrutura biométrica – Componentes principais da plataforma

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

KEYWORDSELECTOR

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

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

Manipular dados de modelo

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

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 do IStream com armazenamento apropriado para até 1 MB de dados.

O conteúdo e a estrutura dos dados nesse armazenamento são definidos pelo OEM. A finalidade pretendida é para 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, particularmente se o usuário nunca treinou uma 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 apenas um usuário.

O desenvolvedor OEM DLL decide como gerenciar os dados independentes e dependentes do usuário. No entanto, ele nunca armazenará dados do usuário fora do IStream. Um possível design de DLL OEM alternaria internamente entre acessar o IStream e os dados independentes do usuário estático, 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 independentes do usuário estático 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.

Treinamento e processamento de áudio de operação

Conforme descrito anteriormente, o fluxo da interface do usuário de treinamento resulta em frases foneticamente ricas e completas disponíveis no fluxo de áudio. Cada frase é passada individualmente para IKeywordDetectorOemAdapter::VerifyUserKeyword para verificar se contém a palavra-chave esperada e tem qualidade aceitável. Depois que todas as sentenças 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 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 Bruto ou Fala
Afixar 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
Mic Mic 0 Todos os microfones em array ou mono

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

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

Diagrama do sistema de reconhecimento de palavras-chave, incluindo Cortana, tempo de execução 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 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, os recursos são coletados usando IKeywordDetectorOemAdapter::GetCapabilities.

Diagrama de sequência de reconhecimento de palavras-chave durante a inicialização, mostrando a UX de treinamento, a plataforma de fala e o detector de palavras-chave OEM.

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

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

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

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

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

As soluções HW-KWS 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 de dispositivo DEVPKEY_KsAudio_PacketSize_Constraints na interface de dispositivo PnP KSCATEGORY_AUDIO do filtro KS que tem o(s) pino(s) de streaming KS. Esta propriedade deve permanecer válida e estável enquanto a interface do filtro KS estiver ativada. O sistema operacional pode ler esse valor a qualquer momento sem ter que 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 descrevendo restrições específicas para qualquer modo de processamento de sinal. O driver define essa propriedade antes de chamar PcRegisterSubdevice ou ativar sua interface de filtro KS para seus pinos de streaming.

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 implementa opcionalmente essa interface para ser avisada do 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 de driver retornam carimbos de data/hora do contador de desempenho do Windows refletindo a hora em que as amostras são capturadas ou apresentadas pelo dispositivo.

Em dispositivos que têm pipelines DSP complexos e processamento de sinais, calcular um carimbo de data/hora preciso pode ser um desafio e deve ser feito com cuidado. Os carimbos de data/hora não devem simplesmente refletir a hora em que as amostras foram transferidas de ou para o SO para o DSP.

  • Dentro do DSP, rastreie os carimbos de data/hora de amostra 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 precisos) a bastante complexos ou novos (mas mais precisos).
  • Considere quaisquer atrasos constantes devido a algoritmos de processamento de sinal ou transporte 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 acontecer fora do cenário de ativação de voz, desde que o driver ofereça suporte ao modelo WaveRT de streaming baseado em pacote, incluindo a função IMiniportWaveRTInputStream::GetReadPacket.

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

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

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

  2. 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), a partir 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 instante de amostragem da primeira amostra no pacote. Observe que 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 no driver (fora do buffer WaveRT).

    c. Se houver mais dados armazenados em buffer não lidos disponíveis, o driver: i. Transferirá imediatamente esses dados para o espaço disponível do buffer WaveRT (ou seja, espaço não usado pelo pacote retornado de GetReadPacket), retornará true para MoreData e definirá o evento de notificação de buffer antes de retornar dessa rotina. Ou ii. Programará o hardware para acionar o próximo pacote no espaço disponível do buffer WaveRT, retornará false para MoreData e, posteriormente, definirá o evento de 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 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).

  5. Se o driver não definiu imediatamente o evento na etapa (2c), ele definirá o evento depois de transferir mais dados capturados para o buffer WaveRT e disponibilizará para a leitura do sistema operacional.

  6. Vá para (2). Para pinos de detector de palavras-chave KSNODETYPE_AUDIO_KEYWORDDETECTOR, os drivers devem alocar buffer de intermitência interno suficiente para pelo menos 5.000 ms de dados de áudio. Se o sistema operacional falhar ao criar um fluxo no pino antes que o buffer estoure, o driver poderá encerrar a atividade de buffer interno e liberar recursos associados.

Ativação por voz

A Ativação por voz (WoV) permite que o usuário ative e consulte um mecanismo de reconhecimento de fala de uma tela desligada, estado de economia de energia, para uma tela ligada no estado de energia total, dizendo uma determinada palavra-chave, como "Ei, Cortana".

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

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

Validação em sistemas de modo de espera moderno

O WoV de um estado ocioso do sistema pode ser validado em Sistemas de modo de espera moderno usando o Teste básico de ativação por voz em espera moderna com fonte de alimentação CA e o Teste básico de ativação por voz em espera moderna com fonte de alimentação CC no HLK. Esses testes verificam se o sistema tem um identificador de palavras-chave de hardware (HW-KWS), é capaz de entrar no estado mais profundo de ociosidade de runtime da plataforma (DRIPS) e é capaz de despertar do modo de espera moderno no comando de voz com latência de retomada do sistema menor ou igual a um segundo.