Несколько голосовых помощников

Платформа Множественных голосовых ассистентов обеспечивает поддержку дополнительных голосовых ассистентов в Windows. Это позволяет другим помощникам быть доступным на устройствах Windows, таких как компьютеры и носимые устройства, такие как HoloLens. Несколько голосовых помощников могут быть активными на одном устройстве с помощью набора поддерживаемых шаблонов ключевых слов.

Сведения о реализации Windows Кортаны см. в разделе "Активация голосовой связи".

Активация голосовой связи

Активация голосовой связи — это функция, которая позволяет пользователям вызывать подсистему распознавания речи из различных состояний питания устройства, говоря определенную фразу.

Реализация голосовой активации является значительным проектом и является задачей, выполненной поставщиками SoC. Изготовители оборудования могут обратиться к поставщику SoC для получения сведений о реализации активации голосовой связи SoC.

Активация голосовой связи позволяет пользователям быстро взаимодействовать с голосовой помощником за пределами активного контекста (т. е. то, что сейчас на экране) с помощью голоса. Пользователи часто хотят мгновенно получить доступ к интерфейсу без физического взаимодействия с устройством или касания устройства. Для пользователя Xbox это может быть связано с нежеланием искать и подключать контроллер. Пользователям пк может потребоваться быстрый доступ к интерфейсу без необходимости выполнять несколько действий мыши, касания и /или клавиатуры, как в случае компьютера на кухне.

Голосовая активация осуществляется с помощью определителя ключевых слов (KWS), который реагирует, если обнаружена ключевая фраза. Ключевые фразы могут включать ключевые слова, такие как "Hey Contoso". Обнаружение ключевых слов описывает обнаружение ключевого слова по оборудованию или программному обеспечению.

Ключевые фразы могут произноситься сами по себе ("Hey Contoso") как поэтапная команда или за ними следует речевое действие, составляющее составную команду ("Hey Contoso, где находится мое следующее собрание?")

Корпорация Майкрософт предоставляет средство обнаружения ключевых слов по умолчанию ОС (средство обнаружения ключевых слов программного обеспечения) для предоставления голосового помощника в случаях, когда обнаружение ключевых слов оборудования недоступно. Хотя в настоящее время это доступно для Кортаны, для подключения других голосовых помощников может потребоваться дополнительная конфигурация Майкрософт для обнаружения двухэтапных ключевых слов. Для получения дополнительных сведений свяжитесь с [email protected].

Если KWS используется для пробуждения устройства из состояния низкого энергопотребления, это решение называется пробуждением по голосу (WoV). Дополнительные сведения см. в статье "Пробуждение по голосовой связи " далее в этой статье.

Глоссарий терминов

В этом глоссарии приведены термины, связанные с активацией голосовой связи.

Интеграция аппаратного устройства распознавания ключевых слов

Для реализации средства обнаружения ключевых слов оборудования (HW KWS) поставщики SoC должны выполнить следующие задачи.

• Создайте настраиваемый детектор ключевых слов на основе примера SYSVAD, описанного далее в этом разделе. Эти методы будут реализованы в COM-библиотеке DLL, описанной в интерфейсе адаптера OEM детектора IEvent.
• Реализуйте усовершенствования WAVE RT, описанные в разделе "Усовершенствования WAVERT".
• Предоставьте записи INF-файла для описания любых пользовательских API, используемых для обнаружения ключевых слов.
  • 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
• Ознакомьтесь с рекомендациями по оборудованию и тестом в рекомендации по аудиоустройствам. В этом разделе приведены рекомендации и рекомендации по проектированию и разработке устройств ввода звука, предназначенных для использования с платформой распознавания речи Майкрософт.
• Поддерживаются поэтапные и последовательные команды.
• Соответствие локальным требованиям голосовых помощников
• Объекты обработки звука (APOs) должны обеспечить следующие эффекты:
  • AEC
  • AGC
  • НС
• Эффекты для режима обработки речи должны быть сообщены MFX APO.
• APO может выполнять преобразование формата в виде MFX.
• APO должен выводить следующий формат:
  • 16 кГц, mono, FLOAT.
• При необходимости создайте любые пользовательские API для улучшения процесса записи звука. Дополнительные сведения см. в Windows объектах обработки звука.

Требования к аппаратному разгрузчику ключевых слов (HW KWS) WoV

• HW KWS WoV поддерживается во время рабочего состояния S0 и состояния сна S0, также известного как Современный режим ожидания.
• HW KWS WoV не поддерживается из S3.

AEC

AEC может выполняться процессором DSP во время записи коротких фрагментов звука или осуществляться позже с помощью аудиообработки APO. Для выполнения программного обеспечения AEC с данными о всплесках KWS необходимо иметь соответствующее петлевое аудио с момента захвата данных о всплесках. Для этого был создан специальный аудиоформат для выходного всплеска, который встроит звук обратной передачи в данные всплеска звука.

Начиная с версии Windows 20H1, Microsoft AEC APO осознает этот чередующийся формат и может его использовать для выполнения функции AEC. Дополнительные сведения см. в KSPROPERTY_INTERLEAVEDAUDIO_FORMATINFORMATION.

Ратификация

Проверьте аппаратную поддержку для свойств KSPROPSETID_SoundDetector2 с помощью тестов Voice Activation Manager 2.

Обзор примера кода

Существует пример кода для звукового драйвера, реализующего активацию голосовой связи на GitHub в рамках примера виртуального звукового адаптера SYSVAD. Рекомендуется использовать этот код в качестве отправной точки.

Дополнительные сведения о примере звукового драйвера SYSVAD см. в разделе "Примеры звуковых драйверов".

Сведения о системе распознавания ключевых слов

Поддержка звукового стека голосовой активации

Внешние интерфейсы звукового стека для включения активации голосовых функций служат каналом связи для платформы речи и аудиодрайверов. Внешние интерфейсы делятся на три части.

• Интерфейс драйвера устройства детектора событий (DDI). Интерфейс драйвера устройства детектора событий отвечает за настройку и активацию аппаратного обеспечения для точечного поиска ключевых слов (KWS). Он также используется драйвером для уведомления системы события обнаружения.
• DLL-адаптер OEM для детектора IEvent. Эта библиотека DLL реализует COM-интерфейс для адаптации непрозрачных данных, специфичных для драйвера, с целью их использования операционной системой для обнаружения ключевых слов.
• Усовершенствования WaveRT Усовершенствования позволяют звуковому драйверу передавать поток буферизованных звуковых данных после обнаружения ключевых слов.

Свойства конечной точки аудио

Построение графа аудиовыхода происходит нормально. Граф подготовлен для обработки данных быстрее, чем их захват в реальном времени. Метки времени захваченных буферов остаются точными. В частности, метки времени будут правильно отражать данные, которые были записаны в прошлом и буферизованном, и теперь рвутся.

Теория обходного пути потоковой передачи аудио через Bluetooth

Драйвер предоставляет фильтр KS для устройства записи как обычно. Этот фильтр поддерживает несколько свойств KS и событие KS для настройки, включения и индикации события обнаружения. Фильтр также включает дополнительную фабрику пинов, определяемую как ключевой (KWS) пин. Этот контакт используется для потоковой передачи звука из голосового активатора.

Свойство: KSPROPSETID_SoundDetector2

Все свойства KSPROPSETID_SoundDetector2 вызываются со структурой данных KSSOUNDDETECTORPROPERTY . Эта структура данных содержит идентификатор события KSPROPERTY и идентификатор события для ключевого слова, который необходимо вооружить, сбросить, обнаружить и т. д.

• Поддерживаемые типы ключевых слов — KSPROPERTY_SOUNDDETECTOR_PATTERNS. Это свойство задается операционной системой, чтобы настроить обнаруженные ключевые слова.
• Список GUID шаблонов ключевых слов — KSPROPERTY_SOUNDDETECTOR_SUPPORTEDPATTERNS. Это свойство используется для получения списка идентификаторов GUID, определяющих типы поддерживаемых шаблонов.
• Армирован - KSPROPERTY_SOUNDDETECTOR_ARMED. Это свойство, позволяющее читать и записывать данные, представляет собой булевое значение, указывающее, вооружен ли детектор. ОС задает это для привлечения детектора ключевых слов. ОС может очистить это, чтобы отключиться. Драйвер автоматически очищает это при установке шаблонов ключевых слов, а также после обнаружения ключевого слова. (ОС должна перезапуститься.)
• Результат сопоставления — KSPROPERTY_SOUNDDETECTOR_RESET используется для сброса детектора звука во время запуска.

Во время обнаружения ключевых слов отправляется уведомление PNP, содержащее KSNOTIFICATIONID_SoundDetector. ПРИМЕЧАНИЕ. Это не KSEvent, а событие PNP, которое отправляется с нагрузкой через IoReportTargetDeviceChangeAsynchronous.

KSNOTIFICATIONID_SoundDetector определен в ksmedia.h, как показано здесь.

// 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)

Последовательность операций

Запуск системы

1. ОС отправляет KSPROPERTY_SOUNDDETECTOR_RESET для очистки любого предыдущего состояния детектора, приводя все детекторы в неактивное состояние и удаляя прежние шаблоны.
2. ОС запрашивает KSPROPERTY_SOUNDDETECTOR_PATTERNS, чтобы получить clsid для OEM-адаптера детектора событий.
3. ОС использует адаптер изготовителя детектора событий для получения списка поддерживаемых ключевых слов и языков.
4. ОС регистрирует пользовательские уведомления PNP, отправленные драйвером
5. ОС задает необходимые шаблоны ключевых слов.
6. ОС активирует детектор(ы)

Внутренняя работа драйвера и оборудования

Когда детектор активирован, оборудование может непрерывно осуществлять захват и буферизацию аудиоданных в небольшом буфере FIFO. (Размер этого буфера FIFO определяется требованиями за пределами этого документа, но обычно может составлять сотни миллисекунд до нескольких секунд.) Алгоритм обнаружения работает с потоковой передачей данных через этот буфер. Дизайн драйвера и оборудования таков, что во время работы отсутствует взаимодействие между драйвером и оборудованием, а также нет прерываний процессоров "приложения" до обнаружения ключевого слова. Это позволяет системе достичь более низкого состояния питания, если нет других действий.

Когда оборудование обнаруживает ключевое слово, оно создает прерывание. Ожидая, пока драйвер будет обслуживать прерывание, оборудование продолжает записывать звук в буфер, обеспечивая отсутствие потери данных после ключевого слова в пределах ограничений буфера.

Ключевые метки времени

После обнаружения ключевого слова все решения голосовой активации должны буферизировать всё произнесённое ключевое слово, включая 1,6 секунды до начала ключевого слова. Звуковой драйвер должен предоставить метки времени, определяющие начало и конец ключевой фразы в потоке.

Чтобы поддерживать метки времени начала и окончания ключевого слова, программное обеспечение DSP, возможно, должно будет внутренне помечать события временными метками на основе часов DSP. После обнаружения ключевого слова программное обеспечение DSP взаимодействует с драйвером для подготовки события KS. Драйвер и программное обеспечение DSP должны сопоставить метки времени DSP со значением счетчика производительности Windows. Этот метод предназначен для проектирования оборудования. Одним из возможных решений является чтение текущего счетчика производительности, запрос текущей метки времени DSP, повторное чтение текущего счетчика производительности, а затем оценка корреляции между счетчиком производительности и временем DSP. Затем, учитывая корреляцию, драйвер может сопоставить временные метки DSP с временными метками счетчика производительности Windows.

Интерфейс адаптера OEM для детектора IEvent

OEM предоставляет реализацию COM-объекта, которая выступает в качестве посредника между ОС и драйвером, помогая вычислить или проанализировать непрозрачные данные, записанные и считываемые в звуковой драйвер с помощью KSPROPERTY_SOUNDDETECTOR_PATTERNS и KSPROPERTY_SOUNDDETECTOR_MATCHRESULT.

CLSID объекта COM — это идентификатор GUID шаблона детектора, возвращаемый KSPROPERTY_SOUNDDETECTOR_SUPPORTEDPATTERNS. ОС вызывает CoCreateInstance, передав GUID типа шаблона для создания экземпляра соответствующего COM-объекта, который совместим с типом шаблона ключевых слов, и вызывает методы в интерфейсе IEventDetectorOemAdapter этого объекта.

Требования к модели потоков COM

Реализация OEM может выбрать любую из моделей потоков COM.

IEventDetectorOemAdapter

Структура интерфейса пытается сохранить без отслеживания состояния реализации объекта. Другими словами, реализация не должна хранить состояние между вызовами методов. На самом деле, внутренние классы C++, скорее всего, не нуждаются ни в каких переменных-членах, кроме тех, которые требуются для реализации COM-объекта в целом.

Методы

Реализуйте следующие методы.

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

Усовершенствования для WAVERT

Минипортные интерфейсы определены для реализации драйверами минипорта WaveRT. Эти интерфейсы предоставляют методы для упрощения звукового драйвера, повышения производительности и надежности звукового конвейера ОС или поддержки новых сценариев. Свойство интерфейса устройства PnP определяется, что позволяет драйверу предоставлять статические выражения ограничений размера буфера операционной системе.

Размеры буфера

Драйвер работает под различными ограничениями при перемещении звуковых данных между ОС, драйвером и оборудованием. Эти ограничения могут быть вызваны физическим аппаратным транспортом, который перемещает данные между памятью и оборудованием, а также (или) из-за модулей обработки сигналов в аппаратном или связанном DSP.

Решения HW-KWS должны поддерживать размеры захвата аудио как минимум 100 мс и до 200 мс.

Драйвер задает ограничения размера буфера, устанавливая свойство устройства DEVPKEY_KsAudio_PacketSize_Constraints2 в интерфейсе устройства KSCATEGORY_AUDIO PnP фильтра KS, имеющего пины для потоковой передачи KS. Это свойство должно оставаться допустимым и стабильным во время включения интерфейса фильтра KS. ОС может читать это значение в любое время, не открывая дескриптор для драйвера или вызывая драйвер.

DEVPKEY_KsAudio_PacketSize_Constraints2

Значение свойства DEVPKEY_KsAudio_PacketSize_Constraints2 содержит структуру KSAUDIO_PACKETSIZE_CONSTRAINTS2 , описывающую ограничения физического оборудования (т. е. из-за механики передачи данных из буфера WaveRT в звуковое оборудование). Структура включает массив из 0 или более KSAUDIO_PACKETSIZE_PROCESSINGMODE_CONSTRAINT структур, описывающих ограничения, относящиеся к любым режимам обработки сигналов. Драйвер задает это свойство перед вызовом PcRegisterSubdevice или в противном случае включает интерфейс фильтра KS для своих пин-кодов потоковой передачи.

IMiniportWaveRTInputStream

Драйвер реализует этот интерфейс для улучшения координации потоков аудиоданных от драйвера к ОС. Если этот интерфейс доступен в потоке записи, ОС использует методы этого интерфейса для доступа к данным в буфере WaveRT. Дополнительные сведения см. в разделе IMiniportWaveRTInputStream::GetReadPacket

IMiniportWaveRTOutputStream

Минипорт WaveRT при необходимости реализует этот интерфейс, чтобы получать уведомления о ходе записи от ОС и возвращать точное расположение в потоке. Дополнительные сведения см. в разделе IMiniportWaveRTOutputStream::SetWritePacket, IMiniportWaveRTOutputStream::GetOutputStreamPresentationPosition и IMiniportWaveRTOutputStream::GetPacketCount.

Метки времени счетчика производительности

Некоторые процедуры драйверов возвращают метки времени счетчика производительности Windows, отражающие момент захвата или воспроизведения данных устройством.

На устройствах, имеющих сложные конвейеры DSP и обработку сигналов, вычисление точной метки времени может быть сложной задачей и должно выполняться тщательно. Метки времени не должны просто отражать момент, когда образцы были переданы в ОС или из ОС в DSP.

• В рамках DSP отслеживайте временные метки выборок с помощью некоторых внутренних системных часов DSP.
• Для взаимодействия драйвера и DSP вычислите корреляцию между счетчиком производительности Windows и настенными часами DSP. Процедуры для этого могут отличаться от очень простых (но менее точных) до довольно сложных или новых (но более точных).
• Учитывайте любые постоянные задержки из-за алгоритмов обработки сигналов, конвейера или аппаратного транспорта, если они не учтены иначе.

Операция пакетного чтения

В этом разделе описывается взаимодействие ОС и драйвера для быстрых операций чтения. Циклическое чтение может происходить вне сценария активации голоса, если драйвер поддерживает модель потоковой передачи WaveRT на основе пакетов, включая функцию IMiniportWaveRTInputStream::GetReadPacket.

Рассматриваются два примера сценариев чтения в режиме "burst". В одном сценарии, если минипорт поддерживает разъем с категорией разъема KSNODETYPE_AUDIO_KEYWORDDETECTOR, драйвер начнет записывать и внутренне буферизировать данные при обнаружении ключевого слова. В другом сценарии драйвер может дополнительно буферизовывать данные за пределами буфера WaveRT, если ос не считывает данные достаточно быстро, вызвав IMiniportWaveRTInputStream::GetReadPacket.

Для выгрузки данных, захваченных до перехода на KSSTATE_RUN, драйвер должен сохранять точные данные меток времени вместе с буферизованными данными. Метки времени указывают момент времени отбора захваченных выборок.

1. После перехода потока на KSSTATE_RUN драйвер немедленно задает событие уведомления буфера, так как у него уже есть данные.

2. В этом событии ОС вызывает GetReadPacket(), чтобы получить сведения о доступных данных.

   a. Драйвер возвращает номер пакета допустимых захваченных данных (0 для первого пакета после перехода с KSSTATE_STOP на KSSTATE_RUN), от которого ОС может наследовать позицию пакета в буфере WaveRT, а также положение пакета относительно начала потока.

   б. Драйвер также возвращает значение счетчика производительности, соответствующее моменту выборки первого примера в пакете. Обратите внимание, что это значение счетчика производительности может быть относительно старым, в зависимости от того, сколько данных записи было буферировано в аппаратном или драйвере (за пределами буфера WaveRT).

   с. Если есть более непрочитанные буферизованные данные, доступные драйверу: i. Немедленно передает эти данные в доступное пространство буфера WaveRT (т. е. пространство, не используемое пакетом, возвращаемым из GetReadPacket), возвращает значение true для MoreData и задает событие уведомления буфера перед возвратом из этой процедуры. Или, ii. Программирует оборудование для разрыва следующего пакета в доступное место буфера WaveRT, возвращает false для MoreData, а затем устанавливает событие буфера после завершения передачи.

3. ОС считывает данные из буфера WaveRT с помощью сведений, возвращаемых GetReadPacket().

4. ОС ожидает следующего события уведомления буфера. Ожидание может завершиться немедленно, если драйвер устанавливает уведомление буфера на шаге (2c).

5. Если драйвер не сразу задал событие на шаге (2c), драйвер устанавливает событие после передачи более захваченных данных в буфер WaveRT и делает его доступным для чтения ОС.

6. Перейдите к (2).

Для KSNODETYPE_AUDIO_KEYWORDDETECTOR пинов детектора ключевых слов драйверы должны выделить достаточно памяти для внутреннего буферизации на как минимум 5000 мс звуковых данных. Если ОС не удается создать поток на пине до переполнения буфера, драйвер может завершить внутреннюю буферизацию и освободить связанные ресурсы.

Пробуждение по голосу

Пробуждение на голосовой связи (WoV) позволяет пользователю включить и осуществлять вызов модуля распознавания речи из состояния низкого потребления энергии в полное состояние питания с экраном, произнеся определенное ключевое слово, например, "Hey Contoso."

Эта функция позволяет устройству всегда прослушивать голос пользователя, пока устройство неактивно и экран отключен. Это связано с режимом прослушивания, который использует гораздо меньше энергии по сравнению с обычной записью микрофона. WoV позволяет использовать цепочки речевых фраз, таких как "Hey Contoso, когда моя следующая встреча", чтобы вызывать ответ от голосового помощника в режиме громкой связи.

Стек аудио отвечает за обмен данными активации (идентификатор говорящего, триггер ключевого слова, информация о контексте и уровне достоверности), а также уведомляет заинтересованных клиентов об обнаружении ключевого слова.

Проверка в современных резервных системах

WoV из состояния простоя системы можно проверить на системах с современным режимом ожидания с помощью Основного теста пробуждения по голосу на источнике питания от сети переменного тока и Основного теста пробуждения по голосу на источнике питания от батареи постоянного тока в HLK. Эти тесты проверяют, что система имеет аппаратный детектор ключевых слов (HW-KWS), может перейти в углублённое состояние простоя платформы (DRIPS) и может проснуться по голосовой команде с задержкой возобновления системы не более одной секунды.

ACX и MVA

Аудиокласс eXtension (ACX) определяет расширение класса Windows Driver Framework (WDF) для аудиодомена. Дополнительные сведения о расширениях аудиоклассов ACX см. в обзоре и сводке объектов ACX. В этом разделе описывается, как реализовать MVA с помощью ACX.

ACX использует ту же инфраструктуру KS для обнаружителя ключевых слов, добавляя слой абстракции для упрощения реализации драйвера. С acX тот же DLL OEM используется, как описано выше, и остается неизменным. Для acX и Portcls требуется интерфейс IEventDetectorOEMAdapter, и между ними нет разницы в реализации для адаптера OEM.

Функция AcxKeywordSpotterCreate используется для создания закрытого объекта ключевого слова ACX (ACXKEYWORDSPOTTER), который будет связан с родительским объектом устройства цепи.

Объект ACXKEYWORDSPOTTER используется для замены всех вызовов KSPROPERTY_SOUNDDETECTOR, упрощая реализацию KWS. Он используется в процессе добавления элемента KWS и контакта KWS в схему ACX. Связанные обратные вызовы обеспечивают получение паттернов, активизацию, деактивацию и сброс. Она использует инициализированную структуру ACX_KEYWORDSPOTTER_CONFIG, описывающую конфигурацию поисковика ключевых слов.

Структура ACX_KEYWORDSPOTTER_CONFIG принимает структуру ACX_KEYWORDSPOTTER_CALLBACKS, которая определяет следующие функции обратного вызова.

EvtAcxKeywordSpotterRetrieveArm — обратный вызов ACX_KEYWORDSPOTTER_RETRIEVE_ARM .

EvtAcxKeywordSpotterAssignArm — обратный вызов ACX_KEYWORDSPOTTER_ASSIGN_ARM .

EvtAcxKeywordSpotterAssignPatterns — обратный вызов для ACX_KEYWORDSPOTTER_ASSIGN_PATTERNS.

EvtAcxKeywordSpotterAssignReset — обратный вызов ACX_KEYWORDSPOTTER_ASSIGN_RESET .

Событие ACX PNP

Событие ACX PNP заменяет KSNOTIFICATIONID_SoundDetector, упрощая событие уведомления об обнаружении. Функция ACX_PNPEVENT_CONFIG_INIT инициализирует структуру ACX_PNPEVENT_CONFIG. Входные данные не используются с этой функцией.

Пример кода ACX KWS

Пример кода ACX KWS демонстрирует инициализацию обратных вызовов, элементов ключевых слов и создание системы обнаружения ключевых слов.

{
    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;

Сначала функция AcxKeywordSpotterCreate используется для создания объекта распознавания ключевых слов ACX и связывания его с существующим контуром.

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

Затем определяется контекст выявителя ключевых слов и используется для создания детектора ключевых слов в памяти 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;
    }

В этом примере кода класс CKeywordDetector, добавляемый в контекст, предоставляется только в качестве примера реализации, которая имитирует обнаружение ключевых слов в примере драйвера. Класс CKeywordDetector не является частью платформы ACX и необязательной частью реализации MVA на ACX, но может стать хорошей основой для разработки настоящего детектора ключевых слов.

Наконец, событие ACX PnP создается и настраивается.

   
    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;

}

Каналы с сложным поведением пин-кода, включая KWS

Для схем с сложным поведением пинов, таких как схемы с хост-двигателем и/или KWS, драйвер должен отключить ACX от обработки мостового потока и вместо этого создать мостовой поток без изменения. Этот подход не позволит ACX автоматически связывать потоки с потоковыми мостами.

См. также

Активация голосовой связи