Assistente de Várias Vozes

A plataforma Assistente de Várias Vozes oferece suporte para assistentes de voz adicionais no Windows. Isso permite que outros assistentes estejam disponíveis em dispositivos Windows, como computadores e wearables como o HoloLens. Vários assistentes de voz podem estar ativos no mesmo dispositivo usando um conjunto de padrões de palavra-chave com suporte.

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

Ativação de voz

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.

Implementar a ativação de voz é um projeto significativo e é uma tarefa concluída pelos fornecedores do 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.

A ativação de voz permite que os usuários envolvam 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 ser capazes de acessar instantaneamente uma experiência sem precisar interagir fisicamente com ou tocar em um dispositivo. Para um usuário do Xbox, isso pode ser por não querer encontrar e conectar um controlador. Para usuários de computador, talvez eles queiram acesso rápido a uma experiência sem precisar executar várias ações de mouse, toque e/ou teclado, como no caso de um computador na cozinha.

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

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

A Microsoft fornece um detector de palavra-chave padrão do sistema operacional (software de detecção de palavra-chave) para oferecer a experiência de assistente de voz em casos em que a detecção de palavra-chave de hardware não está disponível. Embora isso esteja disponível no momento para a Cortana, talvez seja necessário uma configuração adicional da Microsoft para adicionar outros assistentes de voz e realizar a detecção de palavras-chave em duas etapas. Para obter mais informações, entre em contato AskMVA@Microsoft.com.

Se o KWS for 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 mais adiante neste artigo.

Glossário de Termos

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

Integrando um hardware de reconhecimento de palavras-chave

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

• Crie um detector de palavras-chave personalizado com base no exemplo SYSVAD descrito posteriormente neste tópico. Você implementará esses métodos em uma DLL COM, descrita na Interface do Adaptador OEM do Detector IEvent.
• Implemente 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.
  • PKEY_FX_KeywordDetector_StreamEffectClsid
  • PKEY_FX_KeywordDetector_ModeEffectClsid
  • PKEY_FX_KeywordDetector_EndpointEffectClsid
  • PKEY_SFX_KeywordDetector_ProcessingModes_Supported_For_Streaming
  • PKEY_MFX_KeywordDetector_ProcessingModes_Supported_For_Streaming
  • PKEY_EFX_KeywordDetector_ProcessingModes_Supported_For_Streaming
• 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.
• Dê suporte a comandos preparados e encadeados.
• Atender aos requisitos de localidade dos assistentes de voz
• 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 MFX APO.
• O APO pode executar a conversão de formato como MFX.
• O APO deve gerar o seguinte formato:
  • 16 kHz, mono, FLOAT.
• Opcionalmente, desenvolva APOs personalizadas para aprimorar o processo de captura de áudio. Para obter mais informações, consulte Objetos de Processamento de Áudio do Windows.

Requisitos de WoV para o detector de palavras-chave descarregado por hardware

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

AEC

A AEC pode ser executada pelo DSP no momento em que o áudio em rajada é capturado, ou pode ser feita posteriormente por meio de um APO de software. Para executar um AEC de software com dados de rajada KWS, é necessário ter o áudio de loopback correspondente a partir do momento em que os dados de rajada foram capturados. Para fazer isso, foi criado um formato de áudio personalizado para a saída de intermitência que interloba o áudio de loopback nos dados de áudio de intermitência.

A partir do Windows versão 20H1, o Microsoft AEC APO está ciente desse 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 de KSPROPSETID_SoundDetector2 com testes do Voice Activation Manager 2.

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.

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

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

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

As interfaces externas do stack de áudio para habilitar a ativação de voz servem como o canal 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 de Driver de Dispositivo) do detector de eventos. A Interface do Driver do Dispositivo do Detector de Eventos é responsável por configurar e armar o KWS (Spotter de palavra-chave) do HW. Ele também é usado pelo driver para notificar o sistema de um evento de detecção.
• DLL do Adaptador OEM do IEvent Detector. 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 do WaveRT. Os aprimoramentos permitem que o driver de áudio transmita em rajadas 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 grafo do ponto de extremidade de áudio ocorre normalmente. O gráfico está preparado para lidar com uma captura mais rápida que o 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 sendo estourados.

Teoria do streaming de áudio com Bluetooth bypass

O driver expõe um filtro KS para seu dispositivo de captura, conforme o habitual. 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 detector de palavras-chave (KWS). Este pino é usado para transmitir áudio do detector de palavras-chave.

A propriedade é: KSPROPSETID_SoundDetector2

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

• 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. Esta propriedade de leitura/gravação é um status simplesmente booliano que indica se o detector está armado. O sistema operacional define isso para envolver o detector de palavras-chave. O sistema operacional pode limpar isso para desengajar. O driver limpa isso automaticamente quando os padrões de palavra-chave são definidos e também depois que uma palavra-chave é detectada. (O sistema operacional deve ser rearmado.)
• Resultado da correspondência – KSPROPERTY_SOUNDDETECTOR_RESET é usado para reiniciar o detector de som no momento da inicialização.

No momento da detecção de palavra-chave, uma notificação PNP que contém KSNOTIFICATIONID_SoundDetector é enviada. OBSERVAÇÃO: este não é um KSEvent, mas sim um evento PNP que é enviado, com uma carga, por meio de IoReportTargetDeviceChangeAsynchronous.

KSNOTIFICATIONID_SoundDetector é definido em ksmedia.h, conforme 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ção

Inicialização do sistema

1. O sistema operacional envia uma KSPROPERTY_SOUNDDETECTOR_RESET para limpar qualquer estado anterior do detector, redefinindo todos os detectores para desarmados e limpando 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 os idiomas com suporte.
4. O sistema operacional registra notificações PNP personalizadas enviadas pelo driver
5. O sistema operacional define os padrões de palavra-chave necessários.
6. O sistema operacional arma os detectores

Operação interna de driver e hardware

Enquanto o detector está armado, o hardware pode capturar e armazenar continuamente dados de áudio em um pequeno buffer FIFO. (O tamanho desse buffer FIFO é determinado por requisitos fora deste documento, mas normalmente pode ser centenas de milissegundos a vários segundos.) O algoritmo de detecção opera no streaming de dados por meio desse buffer. O projeto do driver e do hardware é tal que, quando ativado, não há interação entre o driver e o hardware e nenhuma interrupção nos processadores de "aplicativo" até que uma palavra-chave seja detectada. Isso permite que o sistema atinja um estado de energia mais baixo se não houver outra atividade.

Quando o hardware detecta uma 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 a palavra-chave seja perdida, dentro dos limites de buffer.

Carimbos de data e hora da 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,6s antes do início da palavra-chave. O driver de áudio deve fornecer timestamps que identifiquem o início e o fim da frase-chave no fluxo de dados.

Para dar suporte aos carimbos de data/hora de início/término da palavra-chave, o software DSP pode precisar marcar eventos internamente com base em um relógio DSP. Depois 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 tempo do 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 do DSP atual, leia o contador de desempenho novamente e, em seguida, estime uma correlação entre o contador de desempenho e o tempo DSP. Em seguida, dada a correlação, o driver pode mapear os timestamps de palavra-chave DSP para os timestamps 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 padrão para instanciar o objeto COM apropriado 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 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 variáveis de membro além daquelas necessárias para implementar um objeto COM em geral.

Métodos

Implemente os métodos a seguir.

• IEventDetectorOemAdapter::BuildArmingPatternData
• IEventDetectorOemAdapter::ComputeAndAddUserModelData
• IEventDetectorOemAdapter::GetCapabilities
• IEventDetectorOemAdapter::GetCapabilitiesForLanguage
• IEventDetectorOemAdapter::ParseDetectionResultData
• IEventDetectorOemAdapter::ReportOSDetectionResult
• IEventDetectorOemAdapter::VerifyUserEventData

Aprimoramentos do WAVERT

As interfaces de miniport são definidas para serem implementadas por drivers miniport 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 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.

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

O driver especifica as restrições de tamanho do buffer ao definir a propriedade do dispositivo DEVPKEY_KsAudio_PacketSize_Constraints2 na interface de dispositivo PnP KSCATEGORY_AUDIO do filtro KS que possui 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 do 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 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 que descrevem restrições específicas a quaisquer modos 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

O miniporto WaveRT opcionalmente implementa essa interface para ser avisado do progresso da gravação feita pelo 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 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 carimbo de data/hora preciso pode ser desafiador e deve ser feito com consideração. Os carimbos de data/hora não devem simplesmente refletir o tempo em que as amostras foram transferidas entre o sistema operacional e o DSP.

• No DSP, acompanhe os carimbos de data/hora das amostras usando um relógio interno de referência 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 isso podem variar de muito simples (mas menos preciso) a bastante complexos ou novos (mas mais precisos).
• Considere quaisquer 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 em rajada

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

Dois cenários de leitura de exemplo de intermitência são discutidos. Em um determinado 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 um buffer interno quando uma palavra-chave for detectada. Em outro cenário, o driver poderá opcionalmente armazenar dados em buffer internamente fora do buffer WaveRT se o sistema operacional não estiver lendo dados rapidamente o suficiente chamando IMiniportWaveRTInputStream::GetReadPacket.

Para disparar dados que foram capturados antes da transição para KSSTATE_RUN, o driver deve manter informações precisas de carimbo de data/hora de exemplo, juntamente com os dados de captura em buffer. Os carimbos de data/hora identificam o instante de amostragem dos exemplos capturados.

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), do qual o sistema operacional pode derivar a posição do pacote dentro do buffer WaveRT, bem como a posição do pacote relativa 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 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 poderá: i. Transfere imediatamente esses dados para o espaço disponível do buffer WaveRT (ou seja, espaço não usado pelo pacote retornado do 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 estourar o 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.

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á ser imediatamente encerrada 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), o driver define o evento depois de transferir mais dados capturados para o buffer WaveRT e disponibilizá-lo para o sistema operacional ler

6. Vá para (2).

Para KSNODETYPE_AUDIO_KEYWORDDETECTOR pinos do detector de palavras-chave, os drivers devem alocar buffer em rajadas interno suficiente para pelo menos 5.000ms de dados de áudio. Se o sistema operacional falhar em criar um fluxo no pino antes que o buffer transborde, o driver poderá encerrar a atividade de buffer interno e liberar os recursos associados.

Ativação por Voz

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

Esse recurso permite que o dispositivo esteja sempre escutando a voz do usuário enquanto o dispositivo está ocioso e a tela está desativada. Isso ocorre devido ao modo de escuta que usa muito menos energia em comparação com a gravação normal do microfone. WoV permite que frases de fala encadeadas, como "Ei Contoso, quando é meu próximo compromisso?", sejam usadas para invocar uma resposta de um assistente de voz de forma prática e sem uso das mãos.

A infraestrutura de áudio é responsável por comunicar os dados de ativação (ID do locutor, disparador de palavra-chave, informações de contexto sobre o nível de confiança), bem como informar os clientes interessados que a palavra-chave foi detectada.

Validação em sistemas de espera modernos

O WoV a partir de um estado ocioso do sistema pode ser validado em sistemas Modern Standby usando o Teste Básico de Ativação por Voz no Modo de Espera Moderno com Fonte de Energia AC e o Teste Básico de Ativação por Voz no Modo de Espera Moderno com Fonte de Energia DC no HLK. Esses testes verificam se o sistema tem um spotter de palavra-chave de hardware (HW-KWS), é capaz de entrar no Estado de Plataforma Ociosa do Tempo de Execução Mais Profundo (DRIPS) e é capaz de acordar do Modern Standby por comando de voz com latência de retomada do sistema inferior ou igual a um segundo.

ACX e MVA

O ACX (Audio Class eXtension) 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 a visão geral das extensões de classe de áudio ACX e o resumo dos objetos ACX. Esta seção descreve como implementar o MVA usando o ACX.

O ACX usa a mesma infraestrutura KS para o spotter de palavra-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. Tanto o ACX quanto o Portcls exigem a interface IEventDetectorOEMAdapter e não há nenhuma diferença na implementação entre os dois para o adaptador OEM.

A função AcxKeywordSpotterCreate é usada para criar um objeto opaco do detector de palavras-chave ACX (ACXKEYWORDSPOTTER) que será associado a um objeto pai do dispositivo de circuito.

O objeto ACXKEYWORDSPOTTER é usado para substituir todas as chamadas KSPROPERTY_SOUNDDETECTOR, simplificando a implementação do KWS. Ele é usado no processo de adição de um elemento KWS e um pino KWS ao circuito ACX. Os retornos de chamada associados são responsáveis por obter os padrões, armar, desarmar e redefinir. Ele usa uma estrutura ACX_KEYWORDSPOTTER_CONFIG inicializada que descreve a configuração do detector de palavras-chave.

A estrutura ACX_KEYWORDSPOTTER_CONFIG usa a estrutura ACX_KEYWORDSPOTTER_CALLBACKS, que define as funções de retorno a seguir.

EvtAcxKeywordSpotterRetrieveArm - O retorno de chamada ACX_KEYWORDSPOTTER_RETRIEVE_ARM.

EvtAcxKeywordSpotterAssignArm - O retorno de chamada ACX_KEYWORDSPOTTER_ASSIGN_ARM.

EvtAcxKeywordSpotterAssignPatterns – O retorno de chamada ACX_KEYWORDSPOTTER_ASSIGN_PATTERNS.

EvtAcxKeywordSpotterAssignReset – O retorno de chamada ACX_KEYWORDSPOTTER_ASSIGN_RESET.

Evento ACX PNP

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

Código de exemplo do ACX KWS

O código de exemplo ACX KWS mostra a inicialização dos callbacks, dos elementos de palavra-chave e da criação do detector 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 spotter de palavra-chave 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 detector de palavra-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 dentro do 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 spotter de palavra-chave real.

Por fim, o Evento PnP 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 pin complexo, incluindo KWS

Para circuitos com comportamento complexo de pinos, como circuitos com mecanismo de host e/ou KWS, o driver deve desabilitar o ACX para evitar o gerenciamento do bridge de fluxo e, em vez disso, criar um bridge de fluxo sem o modo inmode. Essa abordagem impedirá que o ACX associe automaticamente fluxos a pontes de fluxo.

Consulte também

Ativação de voz