Комментарии 46
//А вообще, для встроенной карты использую обычные драйвера и ASIO4ALL в секвенсорах, а если подключаю внешнюю карту — встроенный VST
Если копать очень глубоко, то может быть виноват драйвер, работающий мостом, аналогично ASIO4All. Еще причиной тормозов может быть использование USB карты вместо PCI/PCIe.
Ну и тут речь совсем не о качестве. Для качества ASIO явно перебор.
А разницу в ресемплированном звуке c 44кгц до 48кгц (да даже наоборот), пущенному по двум ржавым металлическим вешалкам и по золотому кабелю за $20к, на слух вы заметите только в 2 случаях — эффект плацебо, или же имплантированный в мозг АЦП. Что бы там не говорили аудиофилы.
Касаемо Линукс, уместно будет «Как-то играет и нормально», т.к. платформа или мало привлекает ценителей качественного звука, или потребность в звуке у пользователя Linux далеко не на первом месте.
Если кто с этим не согласен, то:
1. Нет тестов звуковой системы
2. Ограниченное количество звуковых карт, способных работать под Linux
3. Софт для работы со звуком в зачаточном состоянии…
Если хочется доказать, что Linux годен для высококачественного звука, приветите тесты на побитовость выдачи данных со звуковых карт, включая корректную работы автомата опорной частоты. Если таких тестов нет, то могу провести соответствующий тест, но для этого нужен любитель линукса, который сможет в Москве в Soundpal подъехать с компьютером с установленным Linux и звуковой картой с цифровым выходом. Я проведу тест на «Bit Perfect» с помощью Audiolab M-DAC. Процесс можно сфотографировать и сделать материал в виде «как правильно настроить Linux»…
Пока что внятных тестов нет, кроме фанатичной веры в идеальность Linux…
C PulseAudio все немного сложнее, но, как минимум, выбор опорной частоты в нем реализован.
У меня, к сожалению, в лаптопе цифровое аудио только на DisplayPort. Если вы предоставите DisplayPort → S/PDIF переходник, USB-аудиокарту или просто компьютер с цифровым выходом, можно потестировать. В Москве буду 26-27 числа.
Возможно, имело смысл сделать более явный заголовок на тему Windows-only?
P.S. насчет пункта 2 — у меня Windows не видит сама по себе мою ESI juli@, а Linux четко определяет устройство по чипу ICE-чего-то-там и вполне себе играет из коробки. Я это к тому, что не слышал от знакомых о проблемах со звуком на линукс-машинах. Обычно — поставил — заиграло. Можно поподробнее на тему проблемных звуковых карт? Есть мысли поменять карту на внешнюю и, возможно, такая информация, поможет лично мне не сделать Большую Ошибку.
3. Софт для работы со звуком в зачаточном состоянии…Под Линукс есть Bitwig.
Редактор MIDI весьма удобный. Из форматов озвучки поддерживает, как минимум, VST, SF2 и ещё собственный формат.
Что касается, «как-то играет» в MAC, то это будет третий или четвертый пункт. К сожалению, тестов на качество не намного больше, чем на линукс. Но доверия больше, т.к. ОС активно используется в коммерческих проектах, есть шанс, что уделено должное внимание звуковой части.
Было бы интересно узнать, какие плееры в MAC реально работают в монопольном режиме (при воспроизведении из которых уже нет никаких звуков от других программ).
В Linux от звуковой части нужно лишь что бы просто был звук, аналогично режиму PnP в Windows. Отсюда и «хорошо работают», аналогично PnP картам под Windows. Проф. карты имеют множество нестандартных настроек и для раскрытия полной функциональности зачастую нужен отдельный драйвер.
Конкретно под Linux сложно что-то посоветовать, т.к. нет под него отдельного компа или жесткой необходимости в Linux.
Конкретно под Linux сложно что-то посоветовать, т.к. нет под него отдельного компа или жесткой необходимости в Linux.То есть Вы понятия не имеете о фактической ситуации в Linux или MacOS и строите свои умозаключения лишь на экстраполяции опыта работы с Windows и популярности этих систем среди Ваших знакомых. Всё понятно.
У вас есть ссылки на объективные технические тесты, где было бы указано, такая сборка ОС, такая-то звуковая, воспроизвелось из такой-то программы, запись на такое-то устройство и как итог сравнение воспроизведенного и записанного файла, где данные соответствуют «бит-в-бит»?
Основы звуковой подсистемы ОС мало чем отличаются от основ секвенсора и проблемы и решения однотипны.
У вас есть ссылки на объективные технические тестыУ меня нет. Но я и не делаю голословных заявлений.
Основы звуковой подсистемы ОС мало чем отличаются от основ секвенсора и проблемы и решения однотипны.А вот это неправда, в Linux, например, нет особой необходимости в ASIO, тракт и так достаточно гибко конфигурируем, чтобы получить низкую задержку.
У меня складывается впечатление, что Вы вероятно материал прочитали по диагонали и возмущаетесь, что линукс не назван лучшей системой для аудиофилов. В материале подробно рассказано, в чем отличие ASIO от специального режима WASAPI.
Вы можете привести пример сравнения минимальных задержек из под секвенсора в Linux c аналогичным проектом под Windows с ASIO и отдельно WASAPI, что бы утверждать, что Linux достаточно продвинут своими штатными настройками?
Вы голословно утверждаете, что оппонент не правЯ вполне обоснованно утверждаю, что Ваши утверждения голословны, не более. Дискуссии здесь не получится, т.к. Вы балабол.
Разумеется, в user-friendly дистрибутивах уже из коробки установлены и настроены все необходимые модули (плагин dmix для alsa и/или звуковой сервер pulseaudio, работающий поверх alsa — pulseaudio захватывает звуковую карту монопольно, однако все приложения выводят звук через него и он осуществляет микширование), чтобы пользователи не испытывали проблем, но их легко отключить.
Уровень утверждений, независимо от логичности — на «авось», как бы это обидно не было.
Если говорить про мою juli@, она корректно определяется системой, далее тривиальными настройками самого плеера, точнее ALSA, настраивается отключение микширования, задается вывод звука в конкретное устройство (о чем говорит и ValdikSS). Этого должно быть достаточно для получения bit perfect output.
Это я к чему: если смотреть на работу со звуком с колокольни звукорежиссера, допускаю, что Вы правы и весь потенциал карты как то хардварный midi из карты выжать тяжелее (никогда не интересовался). В случае же простого прослушивания звука, честно говоря, не вижу, что может напороть звуковая система Linux, в которой явно можно отключить микширование и указать частоту дискретизации. Лично аппаратное тестирование не проводил, но в сети находится просто ведро описаний как настроить bit perfect в Linux.
Другими словами, то, что для Windows решается установкой ASIO, в Linux решается настройками — поэтому ASIO там не нужно. (Несколько лет назад сдуру пытался найти ASIO для своей карточки под Linux, когда съезжал с Windows. Не найдя, пришлось разбираться в вопросе)
Под простой стерео USB-ЦАП никаких настроек обычно не нужно и тут достаточно только штатных настроек.
Звуковая карта при опросе выдаёт все свои настройки. Драйверу всё равно, как они называются — громкость, переключатель клоков, и т. д. — это уже забота пользователя. В качестве «отдельного драйвера» тут выступает текстовый файл настройки.
Если это исключительно забота пользователя, то чем тогда должен заниматься пользователь, конкретными задачами или настройкой ОС под задачи? Пользователь просто выберет другую ОС.
Это все не к тому, что плохо или хорошо, а к тому, что без внятной готовой панели управления, «сложные» карты неработоспособны.
Я не видел готовых текстовых файлов под серьезные проф. звуковые картыА какие видели? :) Можно найти полно примеров сложных настроек для продвинутых карт. На всякий случай предостерегу от подробного изучения этих конфигов; чтение документации на первом этапе гораздо рациональнее.
Если это исключительно забота пользователя, то чем тогда должен заниматься пользователь, конкретными задачами или настройкой ОС под задачи? Пользователь просто выберет другую ОС.Странно слышать это от человека, рассуждающего о профессиональной обработке звука. Да, ручное написание конфигов не так удобно, как клики по галочкам в окошке, но это — мощный инструмент, позволяющий решить любые задачи и обойти любые проблемы. Месяц на изучение нужно потратить только один раз, зато потом любая карта будет делать именно то, что вы от неё хотите, и вы всегда будете уверены, что выжали из неё возможный максимум.
Программирование Reference Audio Analyzer на C# с попутным изучением C# заняло более 4 лет, а программировать пришлось из отсутствия готовых решений. Если потраченное время на программирование вывести в непрерывный отрезок (5 полноценных дней в неделю), это будет где-то полгода.
Если бы для тестов существовало уже готовое решение, то эти полгода потратились непосредственно на тесты, и протестировано было бы вдвое или трое больше моделей наушников, усилителей и звуковых карт. А так время уходит не на тесты, а на создание инструмента для тестов.
Аналогичная ситуация и с Linux, пользователю необходимо сперва потратить время на «программирование» ОС под свои задачи, вместо того, что бы сразу приступить к выполнению своих задач. А для профессионалов выполнение задач — это заработок и тут «время=деньги». Тем, для кого программирование не является увлечением, намного проще купить ОС, которую не надо программировать.
Для обычной записи без управления эффектами или игрой на виртуальных инструментах низкая задержка не принципиальна.
А причем тут внешний ЦАП, ASIO и звуковая подсистема ОС?
Комп же тупо «цифру» по железному интерфейсу на ЦАП шлет, где она превращается в аналоговый звук.
Или я ошибаюсь?
Мне эта статья почему-то попалась только сегодня. Хоть и прошло шесть лет, но старые заблуждения как вокруг ASIO, так и вокруг звуковой подсистемы Windows, остались до сих пор, так что имеет смысл кое-что пояснить.
Необходимость в ASIO возникла исключительно для профессиональных задач
На самом деле никакой необходимости именно в альтернативном интерфейсе не было. На момент появления ASIO (1997 г.) стандартом был MME/WinMM, и только что появился DirectSound. Никакой централизованной звуковой подсистемы в Windows тогда не было - и MME, и DirectSound работали непосредственно через драйверы ядра, разрабатываемые отдельно для каждого звукового устройства. Преобразования форматов тогда не было - все по определению шло "бит-в-бит". Не было никаких технических проблем и добиться сколь угодно малых задержек, а также добавить к стандартным интерфейсам необходимые дополнительные функции. При этом достаточно было бы одного драйвера для всех приложений - и обычных, и профессиональных.
Общая звуковая подсистема в виде KMixer появилась в Win2k, но там же одновременно появился и Kernel Streaming, которого по уши достаточно для любых применений, если грамотно сделать драйвер. Так что и там не было нужды обходить стандартные интерфейсы - достаточно было (как и сейчас) сделать нормальный драйвер KS, чтобы удовлетворить и массы, и аудиофилов, и профессионалов.
есть специальные режимы, в ОС Windows это «Kernel Streaming» (версии до XP) и WASAPI (версии после XP включительно)
Это просто интерфейсы разного уровня. KS был разработан для модели WDM, общей для Windows 98 и 2000. Это чисто ядерный интерфейс в стиле DirectShow, задумывался как раз для эффективной связки DirectShow на пользовательском уровне с драйверами ядра. Но DirectShow в качестве универсального медийного средства не взлетел, хотя всё видео до сих пор делают почти исключительно на нем. В итоге KS остался этаким "карманным" интерфейсом MS, всех возможностей которого никто никогда не использовал.
В Win2k/XP поверх KS был KMixer, а на нем - MME и DirectSound. В Vista ядерный модуль KMixer заменили на пользовательский процесс AudioDG, который реализует WASAPI.
То есть, WASAPI реализован поверх KS, они существуют вместе.
В таком режиме право передать звуковой поток имеет только одна программа в системе и тут полностью исключается микширование и пересчет данных.
Это все зависит исключительно от KS-драйвера. Почти все они - одноклиентные, как и в раннем MME времен Win3x/9x. Но ничто не мешает сделать мультиклиентный драйвер, KS это полностью поддерживает. Такой драйвер может микшировать и преобразовывать форматы сам, или поручить это звуковому адаптеру, если тот умеет. Первые KS-драйверы для "32-", "64-" и "128-голосых" адаптеров были как раз мультиклиентными, и на этом работало аппаратное ускорение DirectSound в Win2k/XP. Потом обнаружилось, что это мало кому нужно, программный KMixer в большинстве случаев справлялся, и дальше пошли уже одноклиентные драйверы.
WASAPI штатными настройками ОС не позволяет управлять задержкой
Здесь точнее будет сказать "система Windows не позволяет управлять задержкой штатными средствами". :) То есть, ASIO - ни разу не панацея. Если Вы напишете ASIO-драйвер и/или ASIO-хост тупо по спецификации, то обнаружите, что задержки там не сильно меньше, чем в WASAPI, и не более предсказуемы. Это потому, что бОльшая часть задержек возникает в самой системе. независимо от звука. Борьба с ними - отдельный вид шаманства, общие принципы которого описаны здесь (это далеко не всё). А если все эти методы применены, то и WASAPI ведет себя гораздо стабильнее, основной проблемой остается лишь переключение процессов (WASAPI обслуживает отдельный процесс AudioDG).
А вот KS работает по тому же пути, что и ASIO - непосредственно через драйвер ядра. Разница лишь в том, что программно ASIO гораздо проще, а KS значительно более сложен, и спецификация на ASIO была открыта с самого начала, а нормальной документации по KS нет до сих пор, поскольку это неподъемная задача, и MS не видит смысла напрягаться с нею. Из-за этого KS долгое время был практически неизвестен широкой публике, а Steinberg активно продвигал ASIO. В итоге в народе прочно сложилось мнение, что ASIO - это "круто", "профессионально", "надежно", хотя так получилось не "благодаря", а "вопреки". :)
Что происходит, когда задействованы одновременно звуковая система ОС и ASIO? Для звукового драйвера есть два звуковых потока, одни из них приходит из подсистемы ОС, другой из ASIO. Исключительно от того, как был написан драйвер, будет происходить микширование финального потока до ЦАП
Если бы с появлением KS все стали делать ASIO-драйверы исключительно через него, выпуская эффективный мультиклиентный WDM/KS драйвер ядра, и пользовательскую DLL ASIO к нему, то давно настала бы всеобщая благодать. Одним клиентом выступала бы звуковая подсистема, со своим преобразователем форматов, регулятором уровня, эффектами и задержками. Другими клиентами выступали бы ASIO-приложения, сколько их есть. Вдобавок к нему подключались бы KS-приложения. И все это могло бы работать вместе, не мешая друг другу, пока хватает ресурсов у звукового железа (ЦАПов, каналов DMA, ресурсов DSP и прочего). Были бы счастливы все - и обычные пользователи, и аудиофилы, и профессионалы.
Драйвер ASIO4ALL необычайно популярен, но является при этом мостом между выходом ASIO из программы на вход KS/WASAPI в ОС
ASIO4ALL ничего не знает про WASAPI, он работает исключительно через KS. Был еще ASIO2KS, но он не получил такого развития. Через WASAPI работает ASIO2WASAPI.
приходили утверждения со стороны программистов, что например ASIO драйвер внешних карт E-MU (USB версий) сделан аналогично ASIO4ALL в виде моста и именно это является источником низкой стабильности карт
Беда в том, что большинство ядерных драйверов сделано или просто плохо, или ужасно. Многие вообще делаются на WDF - это такой фреймворк от MS для тех, кто очень хочет делать драйверы ядра, но толком не понимает, как там что работает. Я интереса ради ковырял некоторые ASIO DLL и их ядерные драйверы - код там, мягко говоря, странный.
Зачем нужно ASIO для аудиофилов?