Компоненты аудио в режиме пользователя
В Windows Vista основные ИНТЕРФЕЙСы API звука служат основой подсистемы звука в пользовательском режиме. Основные ИНТЕРФЕЙСы API аудио реализованы в виде тонкого слоя системных компонентов пользовательского режима, которые отделяют клиенты пользовательского режима от драйверов аудио в режиме ядра и звукового оборудования. Интерфейсы API звука более высокого уровня, такие как DirectSound и мультимедийные функции Windows, получают доступ к звуковым устройствам через основные API аудио. Кроме того, некоторые звуковые приложения взаимодействуют напрямую с основными API аудио.
Основные ИНТЕРФЕЙСы API аудио поддерживают понятное представление о звуковом устройстве конечной точки. Устройство конечной точки звука — это программное абстракция, представляющее физическое устройство, которое пользователь управляет непосредственно. Примерами устройств конечной точки аудио являются динамики, наушники и микрофоны. Дополнительные сведения см. в разделе "Устройства аудио конечной точки".
На следующей схеме показаны основные API аудио и их связь с другими компонентами звука в режиме пользователя в Windows Vista.
Для простоты на приведенной выше схеме показан только путь к данным отрисовки звука на устройстве конечной точки. Схема не отображает путь к данным записи звука. Основные API аудио включают API MMDevice, WASAPI, API DeviceTopology и API EndpointVolume, которые реализованы в Audioses.dll и Mmdevapi.dll системных модулях пользовательского режима.
Как показано на приведенной выше схеме, основные API аудио обеспечивают основу для следующих ИНТЕРФЕЙСов API более высокого уровня:
- Media Foundation
- Функции Windows multimedia waveXxx и mixerXxx
- DirectSound
- DirectMusic
DirectSound, мультимедийные звуковые функции Windows и Media Foundation (с помощью рендеринга потоковой передачи звука или SAR, компонента) взаимодействуют напрямую с основными API аудио. DirectMusic взаимодействует с основными ИНТЕРФЕЙСами API аудио косвенно через DirectSound.
Клиент WASAPI передает данные устройству конечной точки через буфер конечной точки. Системные компоненты программного обеспечения и оборудования управляют перемещением данных из буфера конечной точки на устройство конечной точки таким образом, что в значительной степени прозрачно для клиента. Кроме того, для устройства конечной точки, подключающегося к звуковому адаптеру с обнаружением джек-присутствия, клиент может создать буфер конечной точки только для устройства конечной точки, который физически присутствует. Дополнительные сведения об обнаружении обнаружения джек-присутствия см. в разделе "Устройства аудио конечных точек".
На предыдущей схеме показаны два типа буфера конечных точек. Если клиент WASAPI открывает поток в общем режиме, клиент записывает звуковые данные в буфер конечной точки, а звуковой модуль Windows считывает данные из буфера. В этом режиме клиент совместно использует звуковое оборудование с другими приложениями, работающими в других процессах. Звуковой модуль смешивает потоки из этих приложений и воспроизводит результирующее сочетание через оборудование. Звуковой модуль — это системный компонент пользовательского режима (Audiodg.dll), который выполняет все операции потоковой обработки в программном обеспечении. В отличие от этого, если клиент открывает поток в монопольном режиме, клиент имеет монопольный доступ к звуковому оборудованию. Как правило, для приложений RTC требуется только небольшое количество "pro audio" или RTC. Хотя на схеме показаны потоки общего режима и монопольного режима, существует только один из этих двух потоков (и соответствующий буфер конечной точки), в зависимости от того, открывает ли клиент поток в общем режиме или в монопольном режиме.
В монопольном режиме клиент может открыть поток в любом звуковом формате, который поддерживает устройство конечной точки. В общем режиме клиент должен открыть поток в формате смешивания, который в настоящее время используется звуковой подсистемой (или формат, аналогичный формату смешивания). Входные потоки звукового модуля и смешивание выходных данных из двигателя находятся в этом формате.
В Windows 7 добавлена новая функция с низкой задержкой для потоков в режиме общего доступа. В этом режиме звуковой модуль работает в режиме извлечения, в котором наблюдается значительное сокращение задержки. Это очень полезно для приложений связи, требующих низкой задержки аудиопотока для ускорения потоковой передачи.
Приложения, которые управляют аудиопотоками с низкой задержкой, могут использовать службу планировщика мультимедиа (MMCSS) в Windows Vista для повышения приоритета потоков приложений, обращаюющихся к буферам конечных точек. MMCSS позволяет звуковым приложениям выполняться с высоким приоритетом, не запрещая ресурсы ЦП более низким приоритетом приложениям. MMCSS назначает приоритет потоку на основе его имени задачи. Например, Windows Vista поддерживает имена задач "Audio" и "Pro Audio" для потоков, которые управляют звуковыми потоками. По умолчанию приоритет потока "Pro Audio" выше, чем в потоке "Аудио". Дополнительные сведения о MMCSS см. в документации по пакету SDK для Windows.
Основные ИНТЕРФЕЙСы API аудио поддерживают форматы потоков PCM и не PCM. Однако звуковой модуль может смешивать только потоки PCM. Таким образом, только потоки в монопольном режиме могут иметь форматы, отличные от PCM. Дополнительные сведения см. в разделе "Форматы устройств".
Звуковой модуль выполняется в собственном защищенном процессе, который отличается от процесса, в котором выполняется приложение. Для поддержки потока в общем режиме аудиослужба Windows (поле с меткой "Аудиослужба" на предыдущей схеме) выделяет буфер конечной точки между процессами, доступный как приложению, так и обработчику звука. В монопольном режиме буфер конечной точки находится в памяти, доступной как приложению, так и звуковому оборудованию.
Аудиослужба Windows — это модуль, реализующий политику звука Windows. Политика аудио — это набор внутренних правил, которые система применяет к взаимодействию между аудиопотками из нескольких приложений, которые совместно используют и конкурируют за использование одного и того же звукового оборудования. Аудиослужба Windows реализует политику аудио, задав параметры управления для звукового модуля. К обязанностям аудиослужбы относятся:
- Отслеживание звуковых устройств, которые пользователь добавляет в систему или удаляет из системы.
- Мониторинг ролей, назначенных звуковым устройствам в системе.
- Управление аудиопотоками из групп задач, которые создают аналогичные классы звукового содержимого (консоль, мультимедиа и коммуникации).
- Управление уровнем громкости объединенного выходного потока ("submix") для каждого из различных типов звукового содержимого.
- Информирование звукового модуля об элементах обработки в путях данных для аудиопотоков.
В некоторых версиях Windows звуковая служба Windows отключена по умолчанию и должна быть явно включена, прежде чем система сможет воспроизводить звук.
В примере, показанном на предыдущей схеме, устройство конечной точки — это набор динамиков, подключенных к звуковому адаптеру. Клиентское приложение записывает звуковые данные в буфер конечной точки, а подсистема аудио обрабатывает сведения о переносе данных из буфера на устройство конечной точки.
Поле с меткой "Звуковой драйвер" на предыдущей схеме может быть сочетанием компонентов драйвера, предоставляемых системой и поставщиком. В случае звукового адаптера на шине PCI или PCI Express система предоставляет системный драйвер класса портов (Portcls.sys), который реализует набор драйверов портов для различных звуковых функций в адаптере, а поставщик оборудования предоставляет драйвер адаптера, который реализует набор драйверов минипорта для обработки операций с устройствами для драйверов портов. В случае с контроллером аудио высокого определения и кодеком на шине PCI или PCI Express система предоставляет драйвер адаптера (Hdaudio.sys), и драйвер, предоставленный поставщиком, не требуется. В случае аудиоадаптера на USB-шине система предоставляет системный драйвер avStream класса (Ks.sys), а также USB-звуковой драйвер (Usbaudio.sys); Опять же, драйвер, предоставленный поставщиком, не нужен.
Для простоты на приведенной выше схеме показаны только потоки отрисовки. Однако основные API аудио также поддерживают потоки записи. В общем режиме несколько клиентов могут совместно использовать захваченный поток с звукового устройства. В монопольном режиме один клиент имеет монопольный доступ к захваченным потоку с устройства.
См. также