Compartilhar via

Assistente de vários estilos de vozes

  • Artigo

A plataforma Assistente de vários estilos de vozes fornece suporte para assistentes de voz adicionais no Windows. Isso permite que outros assistentes estejam disponíveis em dispositivos Windows, como PCs, e dispositivos vestíveis, como HoloLens. Vários assistentes de voz podem estar ativos no mesmo dispositivo usando um conjunto de padrões de palavras-chave compatíveis.

Observação

O Assistente de vários estilos de vozes é suportado a partir do Windows 10 Versão 1903.

Para obter informações sobre como implementar o Windows Cortana, consulte Ativação por voz.

Ativação por Voz

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.

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.

Ela permite que os usuários engajem rapidamente a experiência do assistente de voz fora de 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 ou tocar um dispositivo. Um usuário do Xbox podem usá-la para encontrar e conectar um controle. 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 e/ou teclado, como no caso de um computador na cozinha.

A ativação por voz é alimentada por um identificador de palavras-chave (KWS) que reagirá se a frase-chave for detectada. As frases-chave podem incluir palavras-chave como "Hey Contoso". A detecção de palavras-chave descreve a detecção da palavra-chave por hardware ou software.

As frases-chave podem ser proferidas por si mesmas ("Hey Contoso") como um comando por etapas ou seguidas por uma ação de fala compondo um comando encadeado ("Hey Contoso, onde será minha próxima reunião?")

A Microsoft fornece um identificador de palavras-chave padrão do sistema operacional (identificador de palavras-chave de software) para fornecer experiência de assistente de voz nos casos em que a detecção de palavras-chave de hardware não está disponível. Embora isso esteja atualmente disponível para a Cortana, pode ser necessária uma configuração adicional da Microsoft para integrar outros assistentes de voz para fazer a detecção de palavras-chave em dois estágios. Para obter mais informações, entre em contato com AskMVA@Microsoft.com.

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 neste artigo.

Glossário de Termos

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

Termo Definição/exemplo
Comando por etapas Exemplo: Hey Contoso <pausar, aguardar interface do assistente> 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 Exemplo: "Hey Contoso" – O cenário em que a palavra-chave é detectada em uma frase-chave de ativação predefinida.
Ativação por voz (WoV) 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 "Hey Contoso".
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 de 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 de eventos Um componente de modo de usuário que atua como um intermediário entre a pilha de assistente de voz do Windows e o driver.
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.
MVA Múltiplos assistentes de voz – DDI de HWKWS que suporta vários assistentes.
SVA Assistente de voz único – DDI do HWKWS anterior que suporta apenas um único assistente (Cortana).

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.

AEC

O AEC pode ser executado pelo DSP no momento em que o áudio de bursting é capturado ou pode ser feito em um momento posterior por meio de um software APO. Para executar um software AEC com dados de burst de KWS, é necessário ter o áudio de loopback correspondente a partir do momento em que os dados de burst foram capturados. Para fazer isso, foi criado um formato de áudio personalizado para a saída de burst, que intercala o áudio de loopback nos dados de áudio de burst.

A partir do Windows versão 20H1, o APO de AEC da Microsoft aceita esse formato intercalado e pode usá-lo para executar o AEC. Para obter mais informações, consulte KSPROPERTY_INTERLEAVEDAUDIO_FORMATINFORMATION.

Validação

Valide o suporte de HW para propriedades KSPROPSETID_SoundDetector2 com testes do Gerenciador de Ativação por Voz 2.

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.

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 eventos. O Interface de driver de dispositivo do detector de eventos é 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 IEvent. 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 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.

A propriedade é: KSPROPSETID_SoundDetector2

Todas as propriedadesAll KSPROPSETID_SoundDetector2 são chamadas com uma estrutura de dados KSSOUNDDETECTORPROPERTY. Essa estrutura de dados contém um KSPROPERTY e o ID do evento para a palavra-chave a ser disparada, redefinida, detectada, etc.

  • 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 da correspondência – KSPROPERTY_SOUNDDETECTOR_RESET é usado para redefinir o detector de som no momento da inicialização.

No momento da detecção de palavras-chave, uma notificação PNP contendo KSNOTIFICATIONID_SoundDetector é enviada. NOTA: este não é um KSEvent, mas sim um evento PNP que é enviado com uma carga útil via IoReportTargetDeviceChangeAsynchronous.

KSNOTIFICATIONID_SoundDetector é definido em ksmedia.h como mostrado aqui.

// The payload of this notification is a SOUNDDETECTOR_PATTERNHEADER
#define STATIC_KSNOTIFICATIONID_SoundDetector\
    0x6389d844, 0xbb32, 0x4c4c, 0xa8, 0x2, 0xf4, 0xb4, 0xb7, 0x7a, 0xfe, 0xad
DEFINE_GUIDSTRUCT("6389D844-BB32-4C4C-A802-F4B4B77AFEAD", KSNOTIFICATIONID_SoundDetector);
#define KSNOTIFICATIONID_SoundDetector DEFINE_GUIDNAMED(KSNOTIFICATIONID_SoundDetector)

Sequência de operações

Inicialização do sistema

  1. O sistema operacional envia um KSPROPERTY_SOUNDDETECTOR_RESET para limpar qualquer estado de detector anterior, redefinindo todos os detectores para desativados e limpando os padrões anteriores definidos.
  2. O sistema operacional consulta KSPROPERTY_SOUNDDETECTOR_PATTERNS para recuperar o clsid para o adaptador OEM do detector de eventos.
  3. O sistema operacional usa o adaptador OEM do detector de eventos para recuperar a lista de palavras-chave e idiomas suportados.
  4. O sistema operacional registra notificações PNP personalizadas enviadas pelo driver
  5. O sistema operacional define o(s) padrão(s) de palavra-chave necessário(s).
  6. O sistema operacional aciona o(s) detector(es).

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 1,6 s 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 IEvent

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 IEventDetectorOemAdapter do objeto.

Requisitos do modelo de threading COM

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

IEventDetectorOemAdapter

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.

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 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 IEventDetectorOemAdapter 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_Constraints2

O valor da propriedade DEVPKEY_KsAudio_PacketSize_Constraints2 contém uma estrutura KSAUDIO_PACKETSIZE_CONSTRAINTS2 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 em estado de economia de energia para uma tela ligada no estado de energia total, dizendo uma determinada palavra-chave, como "Hey Contoso".

Esse recurso permite que o dispositivo esteja sempre ouvindo a voz do usuário enquanto o dispositivo está ocioso e a tela está desligada. Isso é devido ao modo de escuta que usa muito menos energia em comparação com a gravação normal do microfone. O WoV permite que frases de fala encadeadas como "Hey Contoso, quando é meu próximo compromisso?" invoquem uma resposta de um assistente de voz de mãos-livres.

A pilha de áudio é responsável por comunicar os dados de ativação (ID do alto-falante, gatilho de palavra-chave, informações de contexto no 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.

ACX e MVA

Audio Class eXtension (ACX) define uma extensão de classe WDF (Windows Driver Framework) para o domínio de áudio. Para obter mais informações sobre o ACX, consulte Visão geral das extensões de classe de áudio ACX e Resumo dos objetos ACX. Esta seção descreve como implementar o MVA usando o ACX.

O ACX usa a mesma infraestrutura KS para o identificador de palavras-chave adicionando uma camada de abstração para simplificar a implementação do driver. Com o ACX, a mesma DLL OEM é usada conforme descrito acima e permanece inalterada. ACX e Portcls exigem a interface IEventDetectorOEMAdapter e não há diferença na implementação entre os dois para o adaptador OEM.

A função AcxKeywordSpotterCreate é usada para criar um objeto opaco de identificador de palavra-chave do ACX (ACXKEYWORDSPOTTER) que será associado a uma entidade principal do objeto de dispositivo de circuito.

O objeto ACXKEYWORDSPOTTER é usado para substituir todas as chamadas KSPROPERTY_SOUNDDETECTOR, simplificando a implementação do KWS. É usado no processo de adição de um elemento e pino KWS ao circuito ACX. Os retornos de chamada associados visam definir padrões, ativar, desativar e redefinir. Ele usa uma estrutura ACX_KEYWORDSPOTTER_CONFIG inicializada que descreve a configuração do identificador de palavra-chave.

A estrutura ACX_KEYWORDSPOTTER_CONFIG usa uma estrutura ACX_KEYWORDSPOTTER_CALLBACKS que define os retornos de chamada a seguir.

EvtAcxKeywordSpotterRetrieveArm – O retorno de chamada de ACX_KEYWORDSPOTTER_RETRIEVE_ARM.

EvtAcxKeywordSpotterAssignArm – O retorno de chamada de ACX_KEYWORDSPOTTER_ASSIGN_ARM.

EvtAcxKeywordSpotterAssignPatterns – O retorno de chamada de ACX_KEYWORDSPOTTER_ASSIGN_PATTERNS.

EvtAcxKeywordSpotterAssignReset – O retorno de chamada de ACX_KEYWORDSPOTTER_ASSIGN_RESET.

Evento PNP de ACX

O evento PNP de ACX substitui KSNOTIFICATIONID_SoundDetector, simplificando o evento de notificação de detecção. A função ACX_PNPEVENT_CONFIG_INIT inicializa uma estrutura ACX_PNPEVENT_CONFIG. Nenhuma entrada é usada com esta função.

Código de exemplo de KWS do ACX

O código de exemplo de KWS do ACX mostra a inicialização dos retornos de chamada, elementos de palavra-chave e criação do identificador de palavra-chave.

{
    NTSTATUS                        status;
    WDF_OBJECT_ATTRIBUTES           attributes;
    ACX_KEYWORDSPOTTER_CALLBACKS    keywordSpotterCallbacks;
    ACX_KEYWORDSPOTTER_CONFIG       keywordSpotterCfg;
    PCODEC_KEYWORDSPOTTER_CONTEXT   keywordSpotterCtx;
    ACX_PNPEVENT_CONFIG             keywordEventCfg;
    ACXPNPEVENT                     keywordEvent;

    PAGED_CODE();

    ACX_KEYWORDSPOTTER_CALLBACKS_INIT(&keywordSpotterCallbacks);
    keywordSpotterCallbacks.EvtAcxKeywordSpotterRetrieveArm = CodecC_EvtAcxKeywordSpotterRetrieveArm;
    keywordSpotterCallbacks.EvtAcxKeywordSpotterAssignArm = CodecC_EvtAcxKeywordSpotterAssignArm;
    keywordSpotterCallbacks.EvtAcxKeywordSpotterAssignPatterns = CodecC_EvtAcxKeywordSpotterAssignPatterns;
    keywordSpotterCallbacks.EvtAcxKeywordSpotterAssignReset = CodecC_EvtAcxKeywordSpotterAssignReset;
    
    ACX_KEYWORDSPOTTER_CONFIG_INIT(&keywordSpotterCfg);
    keywordSpotterCfg.Pattern = &CONTOSO_KEYWORDCONFIGURATION_IDENTIFIER2;
    keywordSpotterCfg.Callbacks = &keywordSpotterCallbacks;
    
    WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE(&attributes, CODEC_KEYWORDSPOTTER_CONTEXT);
    attributes.ParentObject = Circuit;

Em seguida, a função AcxKeywordSpotterCreate é usada para criar o objeto de identificador de palavra-chave de ACX e associá-lo a um circuito existente.

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

Em seguida, o contexto do identificador de palavras-chave é determinado e usado para criar o KeywordDetector na memória NonPagedPoolNx.

    
    keywordSpotterCtx = GetCodecKeywordSpotterContext(*Element);
    ASSERT(keywordSpotterCtx);
    
    keywordSpotterCtx->KeywordDetector = (PVOID) new(NonPagedPoolNx, DRIVER_TAG) CKeywordDetector();
    if (keywordSpotterCtx->KeywordDetector == NULL)
    {
        status = STATUS_INSUFFICIENT_RESOURCES;
        ASSERT(FALSE);
        goto exit;
    }

Neste código de exemplo, a classe CKeywordDetector que é adicionada ao contexto é fornecida apenas como uma implementação de exemplo que simula a detecção de palavra-chave no driver de exemplo. A classe CKeywordDetector não faz parte da estrutura ACX ou uma parte necessária da implementação do MVA no ACX, mas pode fornecer um bom ponto de partida para o desenvolvimento de um identificador de palavra-chave real.

Por fim, o evento PnP do ACX é configurado e criado.

   
    ACX_PNPEVENT_CONFIG_INIT(&keywordEventCfg);
    
    WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE(&attributes, CODEC_PNPEVENT_CONTEXT);
    attributes.ParentObject = *Element;
    status = AcxPnpEventCreate(Device, *Element, &attributes, &keywordEventCfg, &keywordEvent);
    if (!NT_SUCCESS(status))
    {
        ASSERT(FALSE);
        goto exit;
    }

    keywordSpotterCtx->Event = keywordEvent;

    //
    // Done. 
    //
    status = STATUS_SUCCESS;

}

Circuitos com comportamento de pinos complexos incluindo KWS

Para circuitos com comportamento de pino complexo, como circuitos com mecanismo de host e/ou KWS, o driver deve desativar o ACX para que não manipule a ponte de fluxo e, em vez disso, crie uma ponte de fluxo sem inmode. Essa abordagem impedirá que o ACX associe automaticamente fluxos a pontes de fluxo.

Confira também

Ativação por Voz