Basic
Звуковой сигнал, в общем случае, кодируется последовательностью значений амплитуды сигнала, измеренных через равные промежутки времени. Единичное значение амплитуды называют сэмплом, а время между двумя соседними измерениями — частотой дискретизации или частотой квантования. В подавляющем большинстве случаев сэмпл при передаче на аудиоустройство описывают знаковым целым числом — разрядности 16, 24 или 32 бита. Разрядность в 32 бита может быть использована для выравнивания буфера устройства по границе двойного слова, тогда семпл кодируется только первыми 24 битами, или же для полноразрядного кодирования. Первый вариант доступен в ASIO и WASAPI, второй только в WASAPI.
Максимально достижимое соотношение сигнал/шум определяется разрядностью сэмпла и вычисляется как 20log(2^q) где q — разрядность сэмпла.
16 бит — диапазон сэмпла [−32768, 32767], SNR 96.33 дБ 24 бит — диапазон сэмпла [−8388608, 8388607], SNR 144.49 дБ 32 бит — диапазон сэмпла [−2147483648, 2147483647] , SNR 192.66 дБ
Частоты дискретизации (количество сэмплов в секунду для одного канала) из-за взаимной кратности стоит выписать в два набора: {44100, 88200, 192000} и {48000, 96000}. Два набора частот приводят к тому, что аудиоустройству нужно два осциллятора для качественной синхронизации. Конечно, можно использовать и один с кратной частотой, например, как 88200, так и 96000 Гц, но это существенно повышает сложность исполнения точного тактового контура.
Вывод: качественное аудиоустройство должно иметь два осциллятора, один для работы с частотами {44100, 88200}, второй для {48000, 96000, 192000}.
DSP
При обработке цифрового сигнала (DSP — digital sound processing) сэмпл масштабируется как минимум к 64-битному числу с плавающей точкой (double64) в диапазоне от –1 до 1. Наиболее часто применяются преобразования upsampling/downsampling и upscale/downscale. Второе заключается в изменении разрядности сэмпла и в подавляющем большинстве реализаций сводится к простому масштабированию 64-битного double к желаемой битовой разрядности. Данное преобразование помимо масштабирования полезного сигнала делает точно такое же масштабирование и шума, поэтому upscale не меняет соотношение сигнал/шум исходного сигнала, а downscale дополнительно увеличивает долю шума за счет деградации разрядности полезного сигнала.
Upsampling/downsampling очень часто выполняется через решения полинома n-го порядка (как правило, кубического). Берется последовательность из K-сэмплов, и из них рассчитываются коэффициенты интерполирующего полинома, затем полученный полином решается для новых точек семплирования. В идеальном случае, согласно теореме Найквиста-Котельникова, upsampling может только сохранить разрешение исходного сигнала на новой частоте семплирования. В неидеальном случае возможно появления шума на высших гармониках. Интересно, что downsampling после upsampling вернет исходное значение сигнала, даже если после upsampling в нем появились искажения и шум.
В студиях используют алгоритмы, объединяющие upsampling и upscale в единый процесс для увеличения разрешения сигнала и его динамического диапазона. Эти алгори и не могут быть использованы при воспроизведении в реальном времени.
Еще один случай обработки DSP — это convolution (свертка), применимая для адаптации сигнала под акустические свойства комнаты. Здесь исходный сигнал разлагается на гармоники в ряд Фурье до n-го порядка. К сожалению, все быстрые алгоритмы как правило работают с амплитудой сигнала определенной частоты без учета фазы (которую еще очень непросто правильно измерить). Более того, быстрые алгоритмы не решают интеграл, а берут среднее значение в диапазоне. В результате вся коррекция сводится к параметрическому эквалайзеру. Простые полосные фильтры вносят фазовые искажения на частотах разделения, из-за этого параметры convolution нужно еще раз и еще раз подстраивать.
MQA на высоких гармониках, на мой взгляд, инкрементально кодирует первую производную (наклон) функции амплитуды сигнала. Зная частоту гармоник кодировки, простым разложением в ряд Фурье очень просто вытащить и восстановить поведение производной. А имея производную, можно уже делать upsampling не полиномами, а сплайнами со сглаживанием. Вот тогда, уже в реальном времени, можно делать upsampling и upscale с увеличением разрешения и динамического диапазона сигнала. Конечно, это не будет оригинальный Hi-Res, но уже кое-что.
Выводы: Upscale не улучшает соотношение сигнал/шум. Upsampling не улучшает разрешения сигнала. Upsampling имеет смысл для перехода от линейки 44100 к 48000, если осциллятор Вашего устройства лучше для 48000. Использование room correction требует итеративной настройки и, во многом, непредсказуемо.
Русские Блоги
В компьютерной системе, если вам нужно выводить звук, вы должны использовать особый метод для управления звуковыми чипами, такой как кодек, ЦАП и так далее. В процессе мобилизации звукового чипа необходимы некоторые специальные интерфейсы прикладного программирования, то есть аудио API. Используя аудио API, аудио программы, такие как проигрыватели, могут создавать программы вывода непосредственно для API, не используя разные инструкции для разных чипов.
Обычными аудио API являются MME, DS, WDM, KS, WASAPI, ASIO и т. Д.
MME（WaveIn/WaveOut）
MME — это наиболее распространенный Windows Audio API, который называется MutiMedia Extensions, то есть технология расширения мультимедиа. Он имеет долгую историю и хорошую совместимость, и в основном все устройства на рынке могут быть хорошо поддержаны. Он относится к высокоуровневому API и не взаимодействует напрямую с аппаратным обеспечением, ему необходим послойный интерфейс для доступа к аудиооборудованию, что также приводит к высокой задержке. Хотя эта задержка не приводит к ухудшению качества звука при воспроизведении звука, она оказывает большее негативное влияние на обработку и запись звука.
MME использует waveIn **** / waveOut **** API для завершения обработки аудио. После запуска программы используйте функцию серии waveIn ****, чтобы открыть функцию ввода звуковой карты, одновременно установите для буфера достаточно малое значение, а затем начните запись аудиоданных в заданный буфер, а затем в буфер, когда буфер заполнен. (WAVHDR) можно напрямую добавить в очередь вывода функций серии waveOut ****. Этот метод относительно прост в реализации. Недостатком является то, что MME является высокоуровневым API, поэтому ему необходимо пройти через все этапы системной обработки во всем процессе, что приводит к большой задержке. Если буфер слишком мал, он будет вызывать прерывистый звук. Как правило, минимальная задержка может составлять примерно до 120 миллисекунд.
WaveOut — самый ранний метод вывода аудиопотока, предложенный Microsoft, поэтому его совместимость хорошая, его поддерживают практически все операционные системы и звуковые карты Microsoft, но он не может поддерживать функцию «смешивания нескольких аудиопотоков» без использования аппаратного ускорения. , Все действия по микшированию выполняются с использованием программного обеспечения.
DirectSound（DS）
После выпуска Windows95 Microsoft обнаружила, что геймеры по-прежнему готовы использовать DOS в качестве игровой платформы, поскольку разработчики игр обнаружили, что Windows95 не подходит для выполнения видео и аудио задач, поскольку мультимедийные функции, включенные в WinAPI32, слишком медленны для ответа. Затем Microsoft выпустила знаменитый DirectX, DirectX представляет собой набор API аудио и видео DSP (эффект) API аудио. DirectSound является его частью. DirectSound разделен на 2D / 3D. DirectSound имеет эффекторные функции, так что вы также можете добавлять эхо и другие эффекты во время вывода, чтобы имитировать реальную звуковую среду. DirectSound в основном предоставляет сервисы для игр.На некоторых проигрывателях и аудиоредакторах DirectSound также используется в качестве API эффектов в реальном времени. DirectSound фокусируется на выводе, а входные данные отсутствуют. Пока аппаратное обеспечение поддерживает, DirectSound может значительно ускорить ответную реакцию. Скорость отклика звука в Windows была улучшена до нового уровня. За исключением некоторых древних звуковых карт, почти все звуковые карты поддерживают DirectSound, по крайней мере, DirectSound 2D.
В ноябре 2006 года Microsoft выпустила Windows Vista. Vista неожиданно отказалась от поддержки аппаратного уровня DirectSound 3D (HAL), то есть те звуковые карты, которые поддерживают аппаратное ускорение DirectSound 3D, утратили свои возможности ускорения. Недавно выпущенная Windows 7 наследует эту особенность Vista, а аппаратное ускорение DirectSound 3D выходит из исторического прошлого.
DirectX Sound фокусируется на выводе звука и может напрямую обращаться к оборудованию, а скорость отклика была значительно улучшена. Установите режим работы DirectSound на самый высокий уровень, обычно минимальная задержка может составлять около 60 миллисекунд.
WDM
WDM — это аббревиатура от Windows Driver Module, который имеет низкую задержку и поддерживает несколько аудиопотоков. Это новая функция Windows 98 SE / ME / 2000. После появления драйвера WDM люди обнаружили, что звуковые карты, которые ранее не поддерживали несколько аудиопотоков, могут воспроизводить несколько аудиопотоков. WDM также можно рассматривать как набор API. Объектом связи является драйвер, а не обычное приложение. Пока драйвер поддерживает WDM, будет добавлено много функций, таких как таблица мягких волн общего назначения. С точки зрения ввода и вывода, WDM лучше, чем MultiMedia Extensions и DirectSound. Теперь почти все звуковые карты, которые не были исключены, поддерживают WDM. WDM может значительно уменьшить задержку звуковой карты. В некоторых случаях она может быть даже сопоставима с ASIO. В некоторых профессиональных программах для редактирования и создания аудио поддерживается WDM.
MME имеет высокую задержку, а Direct Sound не предназначен для профессионального звука. Появление WDM восполняет эти недостатки. WDM напрямую связывается с драйвером аудиочипа, сокращая большое количество промежуточных каналов и снижая задержку до нового уровня. В настоящее время многие профессиональные аудиопрограммы предоставляют интерфейсы WDM.
Так называемая технология WDM заключается в том, что приложения напрямую вызывают базовые системные службы. Общий процесс — сначала принять данные из буфера, а затем вывести их. Под WinXP аудио WDM также известно как Kernel Streaming (потоковое аудио ядра). Преимущество этой схемы состоит в том, что задержка может быть чрезвычайно низкой, обычно минимальная задержка может составлять от 1 миллисекунды до 10 миллисекунд, и при определенных обстоятельствах память с невыгружаемой памятью, прямой аппаратный IRP и RT могут использоваться для монополизации всех ресурсов звуковой карты.
Kernel Streaming（KS）
Потоковое ядро на китайском означает потоковое ядро, которое является способом прямого доступа к базовым данным, оно может обходить системный микшер (микшер ядра Windows) и напрямую связываться со звуковой картой, что повышает эффективность вывода и уменьшает задержку вывода. , Потоковое ядро не проходит через Kmixer, а напрямую обрабатывает аудиоданные в режиме ядра, чтобы мы могли слышать оригинальный звук.
Тем не менее, Kernel Streaming также имеет свои ограничения: во-первых, использование этого API будет непосредственно занимать аудиооборудование. Когда вы слушаете песню, вы не слышите звук QQ, во-вторых, этот API не имеет функции ввода звука и вы не можете использовать микрофон.
Следует отметить, что с тех пор, как Vista и Win7 начали отказываться от ввода-вывода, зависимого от kmixer и dma, потоковое ядро не применимо к Vista и Win7.
UAA（WASAPI）
UAA — это новейшая звуковая архитектура Windows, которая была представлена при запуске Vista. UAA называется Universal Audio Architecture, то есть универсальной аудио архитектурой, а API для управления звуковыми разговорами — WASAPI (Windows Audio Session API). WASAPI может обрабатывать каждую группу аудио разговоров индивидуально, что имеет большое значение.
Например, при использовании WASAPI, если вы воспроизводите музыку с частотой дискретизации 44,1 кГц, но QQ с частотой дискретизации звука 48 кГц звонит снова, вам не нужно решать ее с реверберацией, и преобразование частоты дискретизации не будет (SRC). Ухудшается качество звука. На самом деле аудио API WASAPI является стандартным для многих любителей музыки.
WASAPI (Windows Audio Session API) — это API-интерфейс, относящийся к аудио-архитектуре UAA (Universal Audio Architecture), которая была добавлена после Windows Vista. WASAPI позволяет передавать немодифицированные битовые потоки на аудиооборудование, тем самым избегая помех SRC (преобразование частоты дискретизации). Для Windows XP каналом, аналогичным WASAPI, является потоковое ядро, упомянутое выше. WASAPI можно использовать только в Vista и Win7 и выше.
Microsoft утверждает, что Vista / 7 начала отказываться от ввода-вывода, зависящего от kmixer и dma, и разработала так называемый WaveRT (Wave RealTime). Их WASAPI, MMCSS и т. Д. Используют WaveRT в качестве ядра, а WaveRT имеет Есть собственный микшер, но вы можете обходить микшер, пока вы запускаете эксклюзивный сенсорный режим, отключите звук всех других программ. MMCSS позволяет вам увеличить приоритет ввода / вывода звука на самые высокие тактовые частоты. Что Microsoft хочет сделать, так это на самом деле использовать таймер управления в реальном времени Аудиопоток, без dma, напрямую обменивается данными с аудиоустройствами UAA или даже позволяет программным часам звуковой карты или аудиоинтерфейса напрямую управлять аудиоданными, эта функция должна быть очень похожа на ASIO, даже если это режим совместного использования WASAPI, SRC больше не существует, но в консоли вы можете свободно устанавливать частоту дискретизации общего назначения, размер бита и каналы после совместного использования микса, чтобы можно было сохранить исходный сигнал 44100 Гц, и это не будет SRC, а теперь все Материнская плата Intel или чипы Intel уже имеют HPET (высокоточный таймер событий), который вы можете сделать Обработка ideo и аудио более точно обрабатывает высокую частоту дискретизации и низкую задержку шины в режиме реального времени, так что число раз, когда на события потока данных можно реагировать в секунду, значительно увеличивается, но я не знаю, есть ли у AMD его.
ASIO
Полное название ASIO — «Audio Stream Input Output», которое представляет собой аудиотехническую спецификацию, предложенную немецкой компанией Steinberg, и является одним из стандартов аудио API. Основными особенностями ASIO являются низкая задержка и многоканальная многоканальная передача. ASIO полностью избавилась от централизованного управления оборудованием операционной системой Windows и может осуществлять многоканальную передачу между программным обеспечением обработки звука и аппаратным обеспечением, одновременно сокращая время реакции системы на аудиопоток до минимального.
Собственный драйвер Windows для MME имеет время задержки 200 ~ 500 мс, DirectSound 50 ~ 100 мс и Mac OS Sound Manager 20 ~ 50 мс. Когда используется ASIO, буфер может быть до Ниже 10 миллисекунд также бывают случаи, когда она меньше 1 миллисекунды из-за лучшей среды. Следовательно, обработка в реальном времени может быть достигнута в операциях записи и производства музыки.
Низкая задержка имеет большое значение для записи звука и пост-производства, но влияние на воспроизведение звука является спорным. Некоторые энтузиасты считают, что низкая задержка ASIO может значительно уменьшить дрожание звука (джиттер), тем самым улучшая качество звука, но есть еще одно высказывание, что ASIO предъявляет строгие требования к аппаратным и программным средам. Если звуковой драйвер написан на общем уровне, Легко создавать такие проблемы, как треск и холодный звук.
EAX
EAX расшифровывается как Environmental Audio Extensions, который не является набором независимых API-интерфейсов, а представляет собой набор 3D-API, созданных на основе DirectSound 3D, его разработчик — известный Creative. Creative запустила EAX, чтобы конкурировать с A3D и в конечном итоге завоевать рынок.После инновационного приобретения Aureal в EAX были внедрены некоторые передовые алгоритмы A3D.
OpenAL
OpenAL — это бесплатный кросс-платформенный аудио-3D API, разработанный Loki Software, но вскоре после этого Loki Software потерпел неудачу: сообщество свободного программного обеспечения заняло дальнейшее развитие, а фактическим лидером стал Creative. Поскольку Vista отказалась от поддержки аппаратного ускорения DirectSound 3D, Creative также оказалась в затруднительном положении: продолжать разработку EAX можно только усилив поддержку OpenAL. Creative надеется на реконструкцию EAX на основе OpenAL. Достичь этого шага несложно, но для широкого использования он нуждается в широкой поддержке со стороны производителей игр. Сегодня поддержка OpenAL по-прежнему не так хороша, как DirectSound 3D, и Creative потребуется время, чтобы воспроизвести его славу. Но если вы попытаетесь добиться успеха, вы можете получить большие преимущества, потому что OpenAL является единственным кроссплатформенным API.
Software player
Я ограничусь рассмотрением Windows-архитектуры, как наиболее доступной и наиболее оптимальной для создания цифрового транспорта. Windows предоставляет три варианта доступа к аудиоустройству: Kernel Streaming, Direct Sound, WASAPI. Плюс подавляющее большинство аудиоустройств поставляются с ASIO-драйвером. Из перечисленных способов только Direct Sound и ASIO являются полноценными аудиоинтерфейсами с возможностями DSP: upsampling/downsampling, upscale/downscale, управлением громкостью и микшированием. Кроме того, ASIO имеет возможность расширения аудиотракта за счет плагинов.
Kernel Streaming и WASAPI являются протоколами низкого уровня для управлений различными устройствами, в том числе и аудио. При этом тяжесть любой DSP-обработки сигнала ложится на программный плеер, использующий эти протоколы. Современные высококачественные программные плееры используют в работе WASAPI и/или ASIO, поскольку оба они предоставляют возможность асинхронной передачи аудиоданных из памяти компьютера в память аудиоустройства.
На всякий случай замечу, что память компьютера и память аудиоустройства — физически разные микросхемы. Программный плеер при работе имеет доступ только к памяти компьютера, где и формирует аудиоданные. Перезапись сформированных данных из одной памяти в другую осуществляется драйвером аудиоустройства.
WASAPI и ASIO имеют практически идентичный принцип работы: плеер подготавливает данные в буфере обмена и указывает протоколу адрес этого буфера, затем он подготавливает следующий буфер и ждет пока протокол не закончит обработку первого. Поскольку процесс подготовки данных и их воспроизведение идут параллельно, то протоколы называют асинхронными. WASAPI в отличие от ASIO имеет два режима работы.
Первый режим — «совместное использование» устройства, когда несколько процессов одновременно могут передавать данные устройству. Второй режим — «эксклюзивный», когда устройство блокируется для монопольного использования только одной программой (одним клиентом). ASIO работает исключительно в эксклюзивном режиме. С точки зрения воспроизведения разницы между WASAPI и ASIO не существует, кроме разве что возможности передачи по WASAPI полноразрядного 32-битного семпла (ASIO если и будет поддерживать такой режим, то все равно будет использовать только первые 24 бита из 32).
Как было отмечено выше, upscale не улучшает соотношение сигнал/шум и, поскольку полноразрядного 32 исходного файла я ни разу не встречал, то и здесь нет никакой разницы между WASAPI и ASIO. Тем не менее, я как программист и как слушатель предпочитаю WASAPI, естественно, в эксклюзивном режиме. Но это дело исключительно вкуса и личных симпатий.
Вывод: если Вы (как и я) воспроизводите аудиосигнал без DSP-обработки, то Вы можете использовать любой (*) программный плеер, поддерживающий WASAPI Exclusive и/или ASIO.
(*) смотри внимательно следующий раздел.
WASAPI, DS, KS, ASIO
Цифра цифрой, но в какой-то момент любители аудио столкнулись с утверждениями, что программные проигрыватели звучат по-разному. Стали субъективно оценивать воспроизведение на foobar2000, jriver, winamp, aimp, aplayer и развеиватели мифов сообщали, что слышат разницу, кому-то один проигрыватель заходил, кому-то другой.
Учитывая проприетарный код многих проигрывателей провести анализ и найти причины такого поведения мы не в силах, но помимо проигрывателя, в воспроизведении аудио участвует и часть операционной системы компьютера. Т.е. это такой компонент, который отвечает за воспроизведение звучания в ОС.
В разных операционных системах аудиосистема разная, и даже в одном семействе операционных систем могут использоваться разные методы взаимодействия с аудио.
Например в Linux изначально использовалась звуковая архитектура OSS (Open Sound System от компании 4Front Technologies),
которая использовалась в профессиональных целях с музыкальным оборудованием — она прекрасно звучала, но здесь произошли коллизии с лицензией — OSS была выпущена тогда под закрытой лицензией, а сообщество требовало GPL. Поэтому разругавшись часть программистов-линуксоидов просто решила написать с нуля аудиосистему и создала ALSA.
Alsa не была лучше (по звучанию даже хуже, по крайней мере на начальном этапе, в настоящий момент не сравнивал), в ней даже нормального микшера не было, пришлось дописать костыль pulseaudio, но были соблюдены GPL-лицензии.
Я помню еще время, когда для лучшего звучания специально выбирал в Linux звуковую архитектуру OSS, чтобы послушать более «вкусное и живое» исполнение в лице Supermax .
На данный момент Alsa доминирует в Linux, а ряд популярных дистрибутивов выпилили OSS даже из ядра, поэтому прикрутить OSS к той же Ubuntu без перекомпиляции ядра просто не получится, а более демократичный Arch Linux вам позволит использовать и OSS. Есть другая небольшая проблема — если раньше все аудиопрограммы были написаны под звуковую архитектуру OSS, и при появлении alsa они не работали (поэтому был написан модуль совместимости и при его установке OSS программы думают, что работают с OSS, хотя на самом деле с «новой» ALSA посредством aoss из пакета alsa-oss), то теперь наоборот — современные линукс-программы работают только с ALSA и уже их придеться обманывать аналогичным модулем для OSS — они будут думать, что работают с ALSA, а на самом деле с OSS (osspd — OSS Proxy Daemon).
Что мне очень нравилось в звуковом ядре OSS — это истинный юникс вей, т.е. абсолютно юниксовый подход — всё есть файлы, и с любым устройством я могу делать все тоже, что и с обычным файлом, копировать в него, с него, читать, писать.
TrueOS — десктопная BSD-система
Ваша звуковая карта в Linux — это файл с названием dsp (а так же audio), который лежит в папке /dev.
Чтобы проиграть музыкальный файл (сырой raw или PCM) я могу просто копировать этот файл (или перенаправить просмотр) в устройство dsp и буду слушать музыку вообще без использования проигрывателей.
Например так
cat music.wav > /dev/dsp
или так
cp mucic.wav /dev/dsp
Ну вы поняли это волшебство силы юникс.
Но, чтобы вас добить, я так же скажу, что раз файл dsp это звуковая карта, то я могу на нее же что-то и записать. Если писать с нее, то она является микрофоном (или другим устройством, если вы измените настройки по умолчанию).
Соответственно я могу вообще без каких либо сторонних программ записать звук с микрофона в файл, вот так например:
cat /dev/dsp > mysound.wav
Вот это все умела OSS. Alsa так не умеет — в ней много костылей, которые приходиться настраивать между собой во множестве конфигурационных файлов. Зато лицензия GPL (сарказм). На самом деле для Linux OSS теперь тоже GPL, но поезд ушел.
Немного перевода с wikipedia:
Изначально проект OSS был свободным программным обеспечением, но после успеха проекта, Саволайнен заключил контракт с компанией 4Front Technologies и запатентовал поддержку новых звуковых устройств и усовершенствований. В ответ сообщество Linux отказалось от реализации OSS, включенной в ядро, и усилия по разработке переключились на замену Advanced Linux Sound Architecture (ALSA). Некоторые дистрибутивы Linux, такие как Ubuntu, решили отключить поддержку OSS в своих ядрах и игнорировать любые ошибки, связанные с пакетами OSS4 (хотя поддержка OSS может быть повторно включена в Ubuntu).
Несмотря на это, несколько операционных систем, таких как FreeBSD, продолжали распространять предыдущие версии OSS и продолжают поддерживать и улучшать эти версии.
В июле 2007 года 4Front Technologies выпустила исходные коды для OSS под CDDL для OpenSolaris и GPL для Linux.
В январе 2008 года 4Front Technologies выпустила OSS для FreeBSD (и других систем BSD) под лицензией BSD.
При этом и OSS и ALSA — это профессиональные и великолепные по качеству аудио архитектуры дающие цифровому звуку прямой доступ к внешнему устройству (сохраняя битперфект разумеется).
Такой идеальный вариант в Windows называется ASIO (Audio Stream Input/Output). И если в Linux архитектура ALSA и в большей части OSS поддерживает все, что у вас выступает в роли аудиокарты, то в Windows на это могут претендовать только устройства со специальными драйверами от производителя, содержащими ASIO (а это далеко не все устройства).
Поэтому прямой кратчайший звук в Linux мы получаем даром, а в Windows не для всех и не всегда, но об этом позже.
OSS в Linux — это не устаревшая система, это современная система, которая и сейчас развивается, последняя версия уже OSS4. Просто в Linux по идейным соображениям (не по звуковым) она задвинута на задний план (смотрите выше).
Но зато в семействе истинно юниксовых операционных систем BSD — FreeBSD, OpenBSD, PC-BSD, TrueOS и тд — OSS единственная звуковая система.
PC-BSD
Кто-то спрашивал на тематическом форуме почему на BSD не портируют ALSA, на что ответили: а зачем, в OSS все есть и без костылей, как в ALSA. Плюс есть конечно и у ALSA — быстрее всего поддержка новых чипов аудио появляется (скорее всего) именно в ней за счет большей поддержки.
Поэтому самый простой путь ощутить прелесть OSS4 — установить ОС на базе BSD .
Аудио опыты с FreeBSD и ее OSS 4.2 я наметил на ближайшее время, а пока вернёмся к WIndows.
В Windows плохой звук?
Для начала неплохо понять о какой Windows вообще речь. Все еще в ходу Windows XP, Windows 7, Windows 8 и тд.
В Windows XP со звуком было все плохо, что у ж говорить, там вы использовали по умолчанию архитектуру DirectSound — очень непрямой путь рассчитанный на добавление игровых эффектов ибо DSound был частью игрового API DirectX.
По картинке мы может увидеть сколь долог путь звука в Windows XP по пути DirectSound. Особенно жестоко портил звук всем знакомый микшер.
Я думаю вы без труда найдете измеренные графики и убедитесь в этом, как сделал я готовясь к написанию этого обзора.
Поэтому было очевидно, что хороший звук можно получить только с ASIO, драйвера на который есть не для любого аудиоустройства.
Но времена XP прошли и настала эпоха Windows Vista/7, которую я тоже не советую сегодня использовать.
Ее схема:
Microsoft пыталась улучшить качество звука результатом чего стала прослойка WASAPI *(Window Audio Service API).
Многие отметили возросшее качество благодаря WASAPI, но стоит отметить, что WASAPI то же далеко не краткий путь (левая часть картинки), так же обратите внимание на блок с названием KST внутри WASAPI — это KS — kernel stream. В программе foobar2000 есть отдельный модуль для реализации kernel stream — его использование сильно сократит путь цифрового звука до аудиоустройства (будет выкинуто всё, что находиться «до»), а так же, логично, лишит вас возможности управлять например громкостью/микшером.
Мы видим, что KS очень схож с ASIO, но к сожалению его реализации достаточно нестабильны и его можно использовать только если на конкретно вашем компьютере он работает и не глючит.
Путь звука через KS — кратчайший
Так же обратите внимание, что никакого DirectSound на который многие любители аудио ругались за качество, здесь (в Vista, 7 и выше) уже нет.
Вы меня можете разоблачить заглянув в устройства в проигрывателе, где такое название будет присутствовать, но это название, как я понимаю, оставлено для совместимости и на самом деле все работает через WASAPI в режиме эмуляции DSound.
Кстати, в самом WASAPI присутствует более короткий эксклюзивный режим WASAPI exclusive mod (очень низкие задержи (latency) до 10 ms), активация которого приводит к удалению из пути звука ряда компонентов, т.е. по сути WASAPI exclusive оставляет на пути только Kernel Stream, т.е. довольствуется меньшей кровью (напомню — отдельный модуль KS нестабилен).
ASIO по-прежнему остается самым кратким, но мы видим, что и Kernel Stream и WASAPI exclusive позволяют нам и без ASIO получить высочайшее качество.
Очень сильно аудиочасть доработана в Windows 10, поэтому именно эту ОС, я бы и посоветовал аудиофилам (или Linux). Windows 10 (1809) в конце 2022 начале 2022 наконец-то выдала в моей системе звучание не уступающее линуксовой ALSA!
Так же отмечу, если вы при прослушивании регулируете громкость звука через микшер Windows — вы ухудшаете звучание. Регулятор громкости в проигрывателе и Windows всегда стоит держать на максимуме, а громкость регулировать на самом усилителе.
Итак, подведем итоги, какой же интерфейс в проигрывателе лучше выбирать.
Если с Linux и BSD вопрос не стоит, там ALSA и OSS, то в Windows у нас есть вариации.
В Windows XP есть только одно качественное решение — это ASIO, при условии наличия таких драйверов на ваше устройство.
Что касается более новых ОС, то конечно стоит перейти на Windows 10 и иметь в виду, что никакого DirectSound уже нет — есть лишь эмуляция этого режима посредством WASAPI (подробнее).
Остается выбор между ASIO, которое доступно не для всех устройств, между KS (kernel stream, который может быть нестабилен) и WASAPI.
Безотносительно стабильности эти вариации распределяются (гипотетически) так (выше — лучше):
1. ASIO
2.KS
3.WASAPI
Путь через WASAPI
ASIO замечателен для популярных сегодня транспортов XMOS, Amanero и тд, но если вы пользуетесь другими устройствами, то драйверов ASIO может просто не существовать.
Продвинутые аудиоманы возразят, что существует универсальный драйвер asio4all, но какой профит вы собираетесь получить с него, если он на самом деле работает через WASAPI?
Т.е. смысла в ASIO4ALL на Windows выше XP никакого нет для прослушивания аудио.
На условном втором месте расположился Kernel Stream (KS), он передает напрямую, как и ASIO данные сразу получателю, в данном случае ЦАП-у, но KS глючный с рядом оборудования, и не факт, что у вас заработает, а кроме того, более менее, вменяемый плагин KS я знаю только для проигрывателя Foobar2000. Итого — KS хорош, он имеет путь короче WASAPI, но он опять же может у вас не работать.
Остается WASAPI. Для аудиофильных задач нас интересует только режим WASAPI exclusive, который фактически отрубает большую часть лишнего оставляя лишь KC и еще немного. Мы получаем дико низкие лэтенси (задержки) вплоть до 10 миллисекунд, как и в ASIO! Ну, на самом деле, у меня есть один ASIO-интерфейс Korg, в нем задержка 1 мс, но это нетипично, даже для ASIO-устройств.
И по сути нет никаких сокровенных причин не использовать нативный, поддерживающий безглючно все и вся WASAPI exclusive получая, по сути, тоже самое, что и в других случаях.
Т.е. гипотетически я бы использовал в первую очередь ASIO. Если не работает, то KS. Если не работает, то WASAPI exclusive. Но по звуку они все дают великолепный звук и нет никакой причины зацикливаться на одно варианте — будет звучание одинаково. Просто выбирайте то, что вам удобнее использовать. И, да, больше нет никакого ужасного, не аудиофильного DSound.
