Обработка звука Hardware-Offloaded
Аппаратно-разгруженная обработка звука позволяет выполнять main задачи обработки звука за пределами main ЦП компьютера.
Обработка звука может быть очень ресурсоемкой с точки зрения вычислений. Поэтому во многих сценариях может быть полезно разрешить выделенному процессору выполнять такие задачи обработки, как, например, смешивание и применение эффектов.
При реализации драйвера для разгрузки звука вы разрабатываете драйвер, который может обрабатывать разгруженные аудиопотоки и предоставлять эту возможность звуковой системе Windows.
В следующих разделах этого раздела рассматривается разработка драйверов, влияние приложений и другие проблемы, которые следует учитывать при разработке звукового драйвера для аудиоадаптера, который реализует аппаратное звуковое ядро для обработки разгруженных аудиопотоков.
Реализация аппаратного драйвера аудиофайла
Вспомогательные интерфейсы для разгрузки обработки звука
Отчеты о сбоях для разгруженного звука
Сведения о разгруженных API см. в разделе Эффекты аппаратной разгрузки APO.
Общие сведения об архитектуре обработки звука Hardware-Offloaded
Звуковой модуль программного обеспечения
На следующей схеме показан звуковой модуль программного обеспечения Windows.
Аудиопотоки поступают в подсистему программного обеспечения со слоя API сеансов звука Windows (WASAPI) и, возможно, через API более высокого уровня, например Media Foundation. В программном обработчике потоковых эффектов (SFX) можно применять для каждого потока, прежде чем отдельные потоки будут смешиваться, а затем передаваться через любые доступные эффекты конечных точек (EFX) и отправляться в оборудование отрисовки и динамики.
Аппаратное звуковое ядро
Аппаратный звуковой модуль реализован в звуковом адаптере и в значительной степени отражает функциональные возможности программного звукового модуля. И хотя Windows поддерживает аппаратно-разгруженную обработку звука, звуковой драйвер для данного звукового адаптера отвечает за предоставление базовых возможностей звукового оборудования, используя топологию, показанную на следующей схеме.
Аппаратное звуковое ядро должно принимать один поток процесса узла и до n разгруженных потоков. Эти разгруженные потоки направляются непосредственно с прикладного уровня для обработки на оборудовании. Иными словами, разгруженные потоки не будут передаваться через звуковой модуль программного обеспечения. На схеме показана реализация, предназначенная для обработки до трех разгруженных потоков. Поток хост-процесса — это окончательные выходные данные программного микшера всех потоков, которые были обработаны в звуковом обработчике программного обеспечения. Каждый аппаратный звуковой модуль также должен содержать аппаратный микшер.
Для поддержания четности с программным звуковым механизмом и интерфейсом WASAPI необходимо, чтобы аппаратный звуковой модуль предоставлял окончательный поток вывода звука обратно в звуковой стек в виде потока замыкания на себя. Это особенно важно для приложений и сценариев, в которых используется подавление акустического эха, для отмены эха и предотвращения обратной связи требуется знание конечного потока вывода.
Чтобы реализовать путь для потока замыкания на себя, звуковой драйвер отвечает за предоставление контакта замыкания на себя. Этот контакт вернет звуковые данные из окончательного вывода обработчика звука, если данные закодированы в формате PCM. В противном случае будет возвращен результат после смешивания (но перед кодировкой). Это означает, что в случае звуковых данных, обрабатываемых с помощью аппаратного EFX-файла, который кодируется в формате, отличном от PCM, поток замыкания на себя принимается непосредственно после аппаратного микшера перед этапом EFX в аппаратном звуковом движке. Сведения о топологии KS-filter, представляющей аппаратное звуковое ядро, см. в разделе Реализация аппаратного драйвера аудиофайла.
Интегрированная аудиоархитектура
На следующей схеме показан обзор результирующей архитектуры, когда аппаратный звуковой модуль работает с программным звуковым механизмом Windows.
В сценарии, где аудиодрайвер указал поддержку разгрузки обработки звука, первые n (в данном случае три) инициализированных потоков будут направляться непосредственно из уровня WASAPI в аппаратное звуковое ядро, минуя программный звуковой модуль. Все новые звуковые потоки после n, поддерживаемых аппаратным звуковым механизмом, будут направляться через программный звуковой модуль для обработки. Результирующий поток из программного звукового модуля затем отправляется аппаратному обработчику звука в качестве потока процесса узла. Поток хост-процесса смешивается с первыми n потоков, применяется обработка EFX, а затем полученный поток отправляется динамикам.
Топология фильтра KS
В Windows 8 и более поздних операционных системах реализована поддержка аппаратного звукового модуля для обработки аудиопотоков. При разработке такого звукового адаптера связанный звуковой драйвер должен предоставлять этот факт звуковой системе пользовательского режима определенным образом, чтобы аудиосистема пользовала, пользовала и правильно предоставляла функции этого адаптера и его драйвера.
Чтобы предоставить аудиодрайверам возможность предоставления аппаратных возможностей этих новых аудиоадаптеров, Windows 8 появилась топология фильтра KS, которую драйвер должен использовать:
Как показано на предыдущем рисунке, топология фильтра KS представляет пути к данным через оборудование, а также показывает функции, доступные по этим путям. В случае звукового адаптера, который может обрабатывать разгруженный звук, в KS-фильтре имеются следующие входные и выходные данные (называемые контактами):
Один контакт хост-процесса. Представляет собой входные данные в фильтр KS из звукового модуля программного обеспечения.
Один замыкания на себя. Он представляет собой выходные данные аппаратного звукового модуля на уровень API аудиосеанса Windows (WASAPI).
Несколько разгруженных аудио пинов. Хотя на рисунке показан только один контакт этого типа, IHV может реализовать любое число (n) контактов.
Фактической службой в аудиосистеме пользовательского режима, которая "ведет" к обнаружению звукового адаптера и его драйвера, является AudioEndpointBuilder. Служба AudioEndpointBuilder отслеживает класс KSCATEGORY_AUDIO для получения и удаления интерфейса устройства. Когда драйвер звукового устройства регистрирует новый экземпляр класса интерфейса устройства KSCATEGORY_AUDIO , срабатывает уведомление о прибытии интерфейса устройства. Служба AudioEndpointBuilder обнаруживает уведомление о прибытии интерфейса устройства и использует алгоритм для проверки топологии звуковых устройств в системе, чтобы она соответствующих действий.
При разработке аудиодрайва для поддержки адаптера, способного обрабатывать разгруженный звук, драйвер должен использовать конечную точку звука KSNODETYPE_AUDIO_ENGINE для предоставления возможностей аппаратного звукового модуля. Дополнительные сведения о процессе обнаружения конечной точки звука см. в разделе Audio Endpoint Builder Algorithm.
Рекомендации по пользовательскому интерфейсу
Вы разработали аудиодрайв для управления базовыми аппаратными возможностями звукового адаптера, который может обрабатывать разгрузку звука. Это означает, что драйвер обладает наилучшими знаниями о том, как управлять функциями адаптера. Поэтому необходимо разработать пользовательский интерфейс, который будет предоставлять пользователям возможности адаптера в виде параметров, которые он может выбирать, включать и (или) отключать.
Если же у вас уже есть пользовательский интерфейс, который используется для управления объектами обработки звука (APOs), которые вы разработали, этот пользовательский интерфейс можно расширить для работы с новым аудиоадаптером. В этом случае расширения пользовательского интерфейса будут обеспечивать управление программным обеспечением для APOs и аппаратное управление для адаптера.
Влияние приложения
Функциональные возможности, описанные для этого нового типа аудиоадаптера и связанного с ним драйвера, могут использоваться приложениями UWP с помощью WASAPI, Media Foundation, обработчика мультимедиа или звуковых> тегов HTML 5<. Обратите внимание, что Wave и DSound нельзя использовать, так как они недоступны для приложений UWP. Также обратите внимание, что классические приложения не могут использовать возможности разгрузки звуковых адаптеров, поддерживающих аппаратно-разгруженный звук. Эти приложения по-прежнему могут отрисовывать звук, но только через пин-код узла, который использует звуковой модуль программного обеспечения.
Если приложение UWP выполняет потоковую передачу содержимого мультимедиа и использует Media Foundation, обработчик мультимедиа или звуковые> теги HTML 5<, приложение автоматически выбирается для аппаратной разгрузки при условии, что для потока задана соответствующая категория звука. Согласие на разгрузку оборудования выполняется для каждого потока.
Приложения UWP, использующие WASAPI или потоковую передачу данных, должны явно согласиться на разгрузку оборудования.