обработка звука Hardware-Offloaded

Аппаратно-выгруженная обработка звука позволяет выполнять основные задачи обработки звука за пределами основного ЦП компьютера.

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

При реализации драйвера для выгрузки звука вы разрабатываете драйвер, который может обрабатывать выгруженные звуковые потоки, а также предоставлять эту возможность звуковой системе Windows.

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

Реализация звукового драйвера с аппаратной разгрузкой

Вспомогательные интерфейсы для обработки звука, переданной на другие системы

Отчеты о глитчах для отключенных звуковых

Сведения о выгруженных APO см. в разделе "Эффекты выгруженных аппаратных APO"

Обзор архитектуры обработки звука Hardware-Offloaded

Программный звуковой модуль

На следующей схеме показан звуковой модуль Windows.

Схема, показывающая архитектуру звукового драйвера с вызовом приложений в эффекты SFX, MFX и EFX, подключение к драйверам и звуковому оборудованию.

Звуковые потоки поступают в программный звуковой модуль из слоя API аудиосеанса Windows (WASAPI) и, возможно, через БОЛЕЕ высокий уровень API, например Media Foundation. Эффекты потоков звукового движка программного обеспечения (SFX) можно применять для каждого потока перед их смешиванием, затем они проходят через доступные эффекты конечных точек (EFX) и отправляются на оборудование вывода и динамики.

Аппаратный звуковой модуль

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

Аппаратный звуковой модуль должен принимать один поток процесса хоста и до n выгруженных потоков. Эти разгруженные потоки направляются непосредственно из уровня приложений в аппаратное обеспечение для обработки. Другими словами, выгруженные потоки не будут передаваться через программный аудиодвижок. На схеме показана реализация, предназначенная для обработки до трех отключенных потоков. Поток хост-процесса — это окончательные выходные данные программного микшера всех потоков, которые были обработаны в программном звуковом движке. Каждый аппаратный звуковой модуль также должен содержать аппаратный миксер.

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

Чтобы реализовать путь к потоку обратной передачи, звуковой драйвер отвечает за предоставление пин-кода обратного цикла. Этот пин-код возвращает звуковые данные из окончательного вывода звукового модуля, если данные кодируются в формат PCM. В противном случае будет возвращен результат после смешивания, но до кодирования. Это означает, что в случае аудиоданных, обрабатываемых аппаратным EFX, кодируемым в формате, отличном от PCM, петлевой поток снимается непосредственно после аппаратного микшера, перед стадией EFX в аппаратном звуковом движке. Информация о топологии KS-фильтра, представляющей аппаратный звуковой движок, см. в разделе «Реализация драйвера аппаратного звука».

Интегрированная архитектура звука

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

Схема интегрированных программных и аппаратных аудиомодулей с вызовом приложения к эффектам SFX, MFX и EFX, подключению к драйверам, аудиооборудованию и петле обратной связи, ведущей обратно к уровню WASAPI.

В сценарии, когда звуковой драйвер указал свою поддержку разгрузки обработки звука, первые n (в данном случае три) потока, которые инициализированы, будут перенаправлены непосредственно из слоя WASAPI на аппаратный звуковой модуль, обходя программный звуковой модуль. Все новые звуковые потоки после n, поддерживаемые аппаратным звуковым механизмом, будут перенаправлены через программный звуковой модуль для обработки. Полученный поток от программного звукового модуля затем отправляется в аппаратный звуковой модуль в качестве потока процесса узла. Поток хост-процесса смешивается с n потоками, выполняется обработка EFX, а затем результирующий поток отправляется на динамики.

Топология фильтра KS

В операционных системах Windows 8 и более поздних версий поддержка была предоставлена для встроенного аппаратного звукового модуля для обработки аудиопотоков. При разработке такого звукового адаптера связанный звуковой драйвер должен выявлять данный факт для аудиосистемы в пользовательском режиме определенным образом, чтобы аудиосистема могла обнаруживать, использовать и корректно раскрывать функции этого адаптера и его драйвера.

Чтобы обеспечить возможность предоставления аппаратных возможностей этих новых звуковых адаптеров, Windows 8 представила топологию KS-filter, которую должен использовать драйвер:

Схема топологии KS-фильтра с входным контактом процесса узла, выгруженным контактом ввода звука и контактом вывода обратного цикла. Аудиообработка, применяемая к выгруженным аудиоконтактам и контакту процесса узла, путь обратной передачи с конечной стадии обработки и двумя потоками через ЦАП из топологии KS-фильтра.

Как показано на предыдущем рисунке, топология KS-filter представляет пути к данным через оборудование, а также функции, доступные на этих путях. Для аудиоадптера, который может обрабатывать выгруженный звук, в фильтре KS есть следующие входные и выходные данные (называемые контактами):

  • Один пин хост-процесса. Это представляет собой данные на вход фильтра KS из программного аудиодвижка.

  • Один штырь обратной петли. Это представляет собой выход данных от аппаратной звуковой системы к слою WASAPI (API аудиосеансов Windows).

  • Ряд отключенных аудиокреплений. Хотя на рисунке показан только один контакт этого типа, IHV может реализовать любое количество (n) контактов.

Фактическая служба в звуковой системе пользовательского режима, которая "ведет" к обнаружению звукового адаптера и его драйвера, является AudioEndpointBuilder. Служба AudioEndpointBuilder отслеживает появление и удаление интерфейсов устройств в классе KSCATEGORY_AUDIO. Когда драйвер аудиоустройства регистрирует новый экземпляр класса интерфейса устройства KSCATEGORY_AUDIO, генерируется уведомление о прибытии интерфейса устройства. Служба AudioEndpointBuilder обнаруживает уведомление о прибытии интерфейса устройства и использует алгоритм для анализа топологии аудиоустройств в системе, чтобы предпринять соответствующие действия.

При разработке звукового драйвера для поддержки адаптера, который способен обрабатывать разгруженное аудио, драйвер должен использовать аудиоконечную точку KSNODETYPE_AUDIO_ENGINE для раскрытия возможностей аппаратного звукового модуля. Дополнительные сведения о процессе обнаружения конечной точки звука см. в разделе "Алгоритм построителя аудиоконечных точек".

Рекомендации по пользовательскому интерфейсу

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

Однако если у вас уже есть пользовательский интерфейс, используемый для управления объектами обработки звука (API), которые вы разработали, этот пользовательский интерфейс можно расширить для работы с новым звуковым адаптером. В этом случае ваши расширения пользовательского интерфейса будут обеспечивать программное управление для АПО и аппаратное управление для адаптера.

Влияние приложения

Функции, описанные для этого нового типа аудиоадаптера и связанного драйвера, могут использоваться приложениями UWP с помощью WASAPI, Media Foundation, Media Engine или HTML 5 <звуковых> тегов. Обратите внимание, что не удается использовать Wave и DSound, так как они недоступны для приложений UWP. Кроме того, обратите внимание, что настольные приложения не могут использовать возможности аппаратной разгрузки звуковых адаптеров, поддерживающих аппаратно-выгруженный звук. Эти приложения все еще могут воспроизводить звук, но только через хостовую шину, которая использует программный аудиодвижок.

Если приложение UWP передает содержимое мультимедиа и использует Media Foundation, Media Engine или HTML 5 <звуковые> теги, приложение автоматически выбирается для аппаратной разгрузки, если для потока задана соответствующая категория звука. Включение аппаратной разгрузки осуществляется для каждого потока отдельно.

Приложения UWP, использующие WASAPI или потоковую передачу данных, должны явно выбрать разгрузку оборудования.

Реализация звукового драйвера с аппаратной разгрузкой

Объекты обработки звука Windows

  • Last updated on