Тестирование методов вывода звука
Чем отличаются методы вывода звука и какой из них лучше использовать? Попытаемся разобраться…
Подопытные методы вывода звука:
- DirectSound
- WASAPI (Shared Mode)
- WASAPI (Exclusive Mode)
- ASIO (ASIO4ALL)
- Kernel Streaming
Конфигурация
- Подопытный плеер: Foobar v1.1.11
Он умеет выводить звук через все интересующие нас методы - ОС: Windows XP Pro SP3 Rus x86 / Windows 7 Ultimate SP1 Rus x86
Windows XP добавлена к тестированию поскольку: KernelStreaming не работает на современных версиях ОС; Реализация DirectSound начиная с Windows Vista претерпела серьезные изменения - Звуковая карта: Virtual Audio Streaming
Виртуальная звуковая карта позволяет исключить особенности железа и реализации драйверов к нему. В добавок к этому, нам будет проще списать с нее выходные данные - Настройки плеера и ОС: 44.1 кГц, 16 Бит/сэмпл, громкость 100%, эквалайзер и другие эффекты выключены
Методика тестирования
Для замеров я использовал RightMark Audio Analyzer (RMAA). В ней сгенерировал тестовый WAV-файл, со следующими характеристиками: 44.1 кГц, 16 Бит/сэмпл. Далее, воспроизводил этот файл в плеере, выбирая различные методы вывода звука, записывал выходной сигнал напрямую в файл и анализировал с помощью той же RMAA.
Тест1: В поисках побитово точного вывода
Первым делом решил протестировать так называемые «побитово точные» методы вывода — WASAPI Exclusive, Kernel Streaming и ASIO (посредством ASIO4ALL). Ходят мнения, поскольку эти методы обходят микшер Windows, то дают наиболее качественный, чуть ли не идеальный звук. Проверим!
Выходной поток будем сравнивать с входным с помощью RMAA, а так же побитово с помощью утилитки сравнения файлов. Поехали!
Нелинейные искажения + шум (при уровне -3 дБ)
Параметры одинаковые, графики совпали. Вроде можно говорить о побитово точном выводе. Но сравнивая входной и выходной файлы с помощью специальной утилитки — наткнулся на странный факт: для ASIO4ALL файлы абсолютно разные, хотя для WASAPI Exclusive и Kernel Streaming полное совпадение.
Причина оказалась в нелинейной фазочастотной характеристике (ФЧХ), а так же в присутствии фазовых задержек:
ASIO4ALL Фазовая задержка
Выводы
WASAPI Exclusive и Kernel Streaming действительно дают побитово точный вывод звука, а вот при использовании ASIO4ALL, формально, ни о каком побитовом выводе речи быть не может. Да, системный микшер ASIO4ALL обходит, но вносит в сигнал собственные искажения в виде нелинейной ФЧХ и фазовых задержек. С другой стороны — фазовые искажения (если они одинаковы во всех каналах) никак не воспринимаются на слух.
Тест2: Оставшиеся методы вывода звука
Нелинейные искажения + шум (при уровне -3 дБ)
Выводы
Что же мы видим? DirectSound в Windows XP оказался очень крут. Побитовое сравнение входного и выходного файла это подтвердило: файлы одинаковые! Честно говоря, я сам не поверил измерениям, но но два повторных измерения дали тот же результат. DirestSound в Windows XP выдает побитово точный вывод звука! Разумеется, это верно, если микшер не работает (отсутствуют другие системные или программные звуки) и системная громкость установлена на 100%.
Если сравнить Direct Sound Windows 7 и WASAPI — первый немного лучше. Но в общем и целом, оба метода вносят совершенно незначительные искажения в исходный сигнал. Едва ли со среднестатистическим оборудованием эту разницу возможно услышать.
Резюме
Что же мы имеем? А имеем мы вот что: три побитово точных метода вывода звука: DirectSound в (Windows XP), WASAPI Exclusive, Kernel Streaming (последний поддерживается считанными Плеерами). Кроме этого мы имеем ASIO (тот, который настоящий, не ASIO4ALL), который мне протестировать не удалось, да и поддерживается он ограниченным количеством устройств. И ещё мы имеем два метода вывода, которые вносят небольшие искажения в исходный сигнал: DirectSound Windows 7 и WASAPI Shared. Но, подчёркиваю, искажения эти настолько незначительны, что на слух их распознать можно лишь имея отнюдь недешевое оборудование.
Какой же метод вывода включить в Плеере?
- Windows XP : однозначно DirectSound — отлично работает, не вносит искажений
- Windows 7 : тут не всё однозначно. Для получения супер-качественного звука можно использовать WASAPI Exclusive или ASIO (при наличии поддержки). Но эти методы блокируют другие звуки в системе, что не всегда удобно. Гораздо удобнее использовать WASAPI или DirectSound.
Kernel Streaming советовать не буду. Пусть этот метод и крут, но его поддержку я встречал лишь у Foobar2000 на уровне «test», и этот метод не работает на ОС начиная с Vista.
Что касается ASIO4ALL : в Windows 7 мы действительно получим небольшое улучшение качества звука (если сравнивать с WASAPI или DirectSound), а вот в Windows XP выгода от использования минимальна: при отсутствии посторонних звуков, идущих на микшер, и 100% системной громкости — местный DirectSound выдает побитово точный звук.
Спасибо за внимание. Надеюсь кому-то данные исследования будут полезны.
Тестирование методов вывода звука : 14 комментариев
А Windows Default это что?
Это вообще не метод вывода, а устройство (наушники или динамики — то, которое вы назначили по умолчанию для вывода звука)
Windows Default — устройство по умолчанию, согласно настройкам ОС. В AIMP-е, для каждого из методов вывода звука (за исключением ASIO), есть свой «Windows Default»
Ну у меня есть выбор или Realtek Hd или DirectSound: Windows Default вот так 🙂 а еще в другом плеере есть DirectSound8 audio slink или это одно и тоже Direct ? 🙂
Покажите лучше скриншоты
А чем можно сделать скриншоты?
Считаю необходимым сделать в AIMP вывод через WSAPI Exclusive. Сейчас для прослушивания lossless использую foobar2000, но один плеер лучше, чем два. Кстати, буду благодарен на ссылку с описанием тракта AIMP3, если таковая информация имеется.
> буду благодарен на ссылку с описанием тракта AIMP3, если таковая информация имеется.
вот http://www.aimp.ru/blogs/?p=88
Попробовал в наушниках послушать FLAC через WSAPI Shared — звук отчётливо чище, особено высокие частоты, но загрузка процессора при этом на уровне 33%, причём 3-е из трёх ядер загружено «в потолок», через DirectSound нагрузка CPU 1-2%. WSAPI Exclusive — к сожалению протестировать не удалось, AIMP виснет, видимо дрова моего SB Audigy для 7-ки не тянут.
Direct Sound однозначно 🙂
Неплохая статья, которая развенчивает многие мифы по поводу суперкачества ASIO
Добавить комментарий Отменить ответ
Для отправки комментария вам необходимо авторизоваться.
WASAPI и PlayPcmWin: разбор
Предисловие
Как известно, выход Windows Vista ознаменовался смертью звуковой подсистемы DirectSound и появление новой подсистемы Windows Audio Session Application Programming Interface (WASAPI). Я уже писал об этом неоднократно — в статье Организация качественного вывода звука и Как вернуть качественный звук в Windows 7.
Лично для меня подобный поворот событий оказался полной неожиданностью. Как я уже писал, в итоге Windows практически полностью потеряла доступ к аппаратным возможностям звуковых карт, а побитовый вывод аудио во многом усложнился. Конечно, надо отметить универсальность, простоту и удобство новой подсистемы — обратная совместимость со старыми приложениями, использующими Wave Out, DS), поддержка любой частоты дискретизации вплоть до 192 кГц, регулировка громкости для каждого приложения. Но, хотя прогресс IT и движется в направлении упрощения, «проще» — далеко не всегда значит «лучше». Скажем, изначально совершенно неизвестно было, каким образом работает ресемплинг WASAPI. Кроме того, в 16-битном режиме микшер вносил какие-то непонятные шумы, сокращающие динамический диапазон на десяток децибел.
Но, не всё так плохо. В WASAPI оказалось заложено много интересных возможностей, позволяющих выполнять тонкую настройку вывода, в том числе качества ресемплирования, латентности и проч. Благо, сейчас разработчики ПО всерьез взялись за реализацию этих возможностей.
Оборудование и ПО
200?’200px’:»+(this.scrollHeight+5)+’px’);»> Intel Core i3 2.93 ГГц, ASUS P7H55-V, 4 ГБ DDR3, Creative X-Fi Xtreme Gamer
Microsoft Windows 7 Ultimate SP1 x64
PlayPcmWin x64 4.0.62
RightMark Audio Analyzer 6.3.0
Adobe Audition CS6
Sony Sound Forge 10.0c
PlayPcmWin
Итак, недавно я разместил на сайте аудиофильский плеер PlayPcmWin, который как раз и предназначен для вывода через WASAPI, и, как следствие, наиболее полно реализует все возможности этого API. Так что начнем знакомство с системой с помощью этого плеера.
Программа имеет две версии — 32- и 64-битную. 64-битная версия позволяет снизить нагрузку на процессор, а также использовать больше оперативной памяти. Мы, как вы уже поняли, будем использовать PlayPcmWin x64.
Давайте запустим программу и рассмотрим элементы её главного окна.
Программа имеет простой и удобный интерфейс. Слева располагается плейлист с поддержкой drag’n’drop, ниже — элементы управления плейлистом и воспроизведением. Справа мы видим базовые настройки, выбор звукового устройства, а также информационные элементы — лог и кнопку получения списка поддерживаемых устройством форматов.
Для начала расскажу о настройках (WASAPI Settings). Настройка Operation mode отвечает за выбор режима воспроизведения — обычный (shared) или монопольный (exclusive). Второй режим доступен только если в настройках звукового устройства Windows включено разрешение его использования. В случае обычного режима, в котором работает большинство программ, написанных для Windows Vista и более новых ОС, Windows Audio Service может использовать все свои обработчики, изображенные на блок-схеме слева:
API — Application Programming Interface
APO — Audio Processing Object
CPT — Cross Process Transport
KST — Kernel Streaming Transport
Этот режим имеет некоторые возможности настройки, но об этом позже. Что касается режима монопольного — в нем отключаются все эти обработчики и звук поступает непосредственно на Kernel Streaming Transport. Так как у данного транспорта только один входной и один выходной поток (смешивание потоков с разных приложений происходит в Mixer APO), подключение непосредственно к KST ведет к блокированию всех остальных звуков.
Настройка Data feed mode отвечает за режим передачи данных, а точнее режим работы программного буфера. Режим Event driven является технически более совершенным, чем Timer driven (иногда называется Push), обладает пониженной нагрузкой на процессор и, как следствие, щелчки (и прочие артефакты) в этом режиме менее вероятны. Однако, есть устройства отказывающиеся работать в Event driven mode, тогда необходимо использовать режим Timer. Стоит отметить, что оба режима позволяют получить побитовое воспроизведение, и к качеству звучания это отношения не имеет.
Параметр латентность позволяет установить размер выходного буфера WASAPI. Это также не имеет отношения к качеству воспроизведения, и влияет лишь на отклик (скорость реакции) на изменения параметров воспроизведения. Однако, слишком низкий размер буфера неминуемо приведет к щелчкам при воспроизведении.
Далее есть очень интересная функция List supported formats. По нажатию на кнопку в поле лога появляется текстовая таблица следующего вида:
200?’200px’:»+(this.scrollHeight+5)+’px’);»> PlayPcmWin 4.0.62.0 64bit
DeviceFriendlyName=Динамики (Creative SB X-Fi)
|| 44kHz i16V16|| 48kHz i16V16|| 88kHz i16V16|| 96kHz i16V16||176kHz i16V16||192kHz i16V16||352kHz i16V16||384kHz i16V16||
|| OK 00000000 || OK 00000000 || OK 00000000 || OK 00000000 || OK 00000000 || OK 00000000 || NA 88890008 || NA 88890008 ||
|| 44kHz i24V24|| 48kHz i24V24|| 88kHz i24V24|| 96kHz i24V24||176kHz i24V24||192kHz i24V24||352kHz i24V24||384kHz i24V24||
|| NA 88890008 || NA 88890008 || NA 88890008 || NA 88890008 || NA 88890008 || NA 88890008 || NA 88890008 || NA 88890008 ||
|| 44kHz i32V24|| 48kHz i32V24|| 88kHz i32V24|| 96kHz i32V24||176kHz i32V24||192kHz i32V24||352kHz i32V24||384kHz i32V24||
|| OK 00000000 || OK 00000000 || OK 00000000 || OK 00000000 || OK 00000000 || OK 00000000 || NA 88890008 || NA 88890008 ||
|| 44kHz i32V32|| 48kHz i32V32|| 88kHz i32V32|| 96kHz i32V32||176kHz i32V32||192kHz i32V32||352kHz i32V32||384kHz i32V32||
|| OK 00000000 || OK 00000000 || OK 00000000 || OK 00000000 || OK 00000000 || OK 00000000 || NA 88890008 || NA 88890008 ||
|| 44kHz f32V32|| 48kHz f32V32|| 88kHz f32V32|| 96kHz f32V32||176kHz f32V32||192kHz f32V32||352kHz f32V32||384kHz f32V32||
|| NA 88890008 || NA 88890008 || NA 88890008 || NA 88890008 || NA 88890008 || NA 88890008 || NA 88890008 || NA 88890008 ||
Это информация о форматах аудио данных, которые поддерживает драйвер звуковой карты, т.е. фактически это форматы, которые могут поступать на Kernel Streaming Transport. Как видно из таблицы, устройство поддерживает стандартные семплрейты от 44.1 до 192 кГц. Что касается разрядности, условные обозначения здесь следующие: ixxVyy означает «xx бит с фиксированной точкой (integer), из них yy битов значащие». Т.е. i16V16 — обычный 16-битный формат с фиксированной точкой, f32V32 — 32-битный с плавающей точкой. i32V24 означает, что к 24-битным данным добавили 8 пустых битов и получили 32-битные. Этот прием используется в случае, когда карта не поддерживает на вход 24-битные данные, как например наша карта X-Fi.
Таким образом карта поддерживает стандартные форматы с фиксированной точкой, кроме 24-битного.
Расширенные настройки
По нажатию кнопки Detailed settings мы попадаем в расширенные настройки программы.
Первая группа настроек относится к монопольному режиму. Здесь можно выбрать формат данных, в котором будет выводиться звук. Здесь следует либо установить параметр в режим автовыбора, либо выбрать поддерживаемый режим с наибольшей разрядностью (см. таблицу). Также здесь можно включить дизеринг (по видимому, с нойз шейпингом), который будет выполняться при понижении разрядности (например, если источник 24-битный, а вывод — 16-битный). Кстати, давайте посмотрим на качество дизеринга.
NS on
NS off
Очень странно — никакого дизеринга, а уж тем более нойз шейпинга здесь не видно. Программа лишь добавляет какой-то странный дополнительный шум. Вероятно, это баг — я уже сообщил об этой странности разработчику.
Добавлено: по словам разработчика, обработка всё же выполняется и называется это формовкой шума первого порядка (first order noise shaping). Т.е. дополнительный шум в запись не вводится, а уже имеющийся шум квантования с помощью специального алгоритма, включающего обратную связь, вытесняется в область высоких частот. Разработчик также утверждает, что в качестве дизера могут запросто выступать естественные шумы микрофона, присутствующие на большинстве записей. Т.е. такой алгоритм даёт преимущественно лучшие результаты на живых, не синтетических записях.
Добавлено: в весрии 4.0.63 была добавлена возможность использовать комбинации dither и noise shaping.
Далее у нас следуют настройки общего режима WASAPI. Здесь мы можем управлять качеством ресемплера (resampler MFT или Audio resampler DSP), входящего в Windows Audio Service. Как написано в документации Microsoft, если программа не выполняет управление качество ресемплера, устанавливается значение по умолчанию — 30. Давайте сравним качество ресемплинга 44.1->96 кГц с качеством 1, 30 и 60 (максимум).
Q=1
Q=30
Q=60
На слух минимальное качество имеет значительные искажения, режимы качества 30 и 60 на слух практически одинаково приемлемы. Кстати, интересно, что управление качеством ресемплинга было введено только в Windows 7.
Здесь же имеется настройка автоматического масштабирования сигнала по амплитуде до 98% от максимума, что предотвращает вмешательство лимитера Windows (иначе он будет компрессировать сигнал).
Что касается режима Shared — с особенностями его работы вы можете ознакомиться в обзоре Windows Media Player.
И последняя группа настроек, которая нас интересует — Playback thread settings, т.е. настройки потока воспроизведения. Здесь мы сталкиваемся с новшеством под названием MMCSS (Multimedia Class Scheduler Service). Эта служба занимается распределением процессорных ресурсов между процессами, отвечающими за выполнение задачи реального времени — записи, воспроизведения (рендеринга). Включив данную функцию (DwmEnableMMCSS(True) и установив тип задачи в Pro Audio, мы тем самым установим для проигрывания максимальный приоритет доступа к ЦП, что позволит еще больше уменьшить латентность (размер буфера). Таким образом, установка режима Pro Audio уменьшает вероятность опустошения буфера (что и является причиной щелчков), однако этот режим менее эффективен с точки зрения эффективности энергопотребления.
В общем, это все, настройки, касающиеся качества воспроизведения. Следует также добавить, что перед воспроизведением плейлиста программа выполняет декодирование и необходимую обработку (например, дизеринг или масштабирование амплитуды), помещая результат в оперативной памяти компьютера в выбранном формате (для монопольного режима используется режим выбранный в настройках, для общего — исходный формат). Вот пример лога после запуска и включения трека:
Продолжительность трека — около 6 минут. После запуска программа потребляла 70 Мб ОЗУ, после включения трека — 212 Мб.
Как вы можете видеть на скриншоте. мне удалось осуществить вывод аудио в формате i32V24 с задержкой всего 3 мс. При этом звуковые артефакты не наблюдались
Что самое интересное — в режиме Shared программа выполняет ресемплирование средствами алгоритма resampler MFT, а затем получает поток обратно, помещая уже ресемпилрованное аудио в ОЗУ (т.е. ресемплинг выполняется не на лету). Вот лог:
После начала произведения программа потребляла около 340 Мб ОЗУ.
PlayPcmWin поддерживает форматы WAV, AIFF, FLAC, а также имеет поддержку CUEsheet.
Выводы
Данная программа, вне всяких сомнений, представляет интерес только для энтузиастов. PlayPcmWin наглядно демонстрирует нам все возможности Windows Audio Service, которые оказались довольно широкими. Несмотря на отсутствие полного доступа к аппаратным ресурсам (как в DirectSound), WASAPI имеет широкие возможности программной обработки звука, а также позволяет организовать вывод звука с низкой задержкой.