Как стать автором
Обновить

Комментарии 46

Было бы еще интересно, если бы вы вкратце рассказали причины «треска», если сильно нагружать ASIO большим количеством VST-плагинов. Как я понимаю, это связано с тем, что буфер не успевает заполнится? Это проблема звуковой карты, жесткого диска или процессора?

//А вообще, для встроенной карты использую обычные драйвера и ASIO4ALL в секвенсорах, а если подключаю внешнюю карту — встроенный VST
При такой постановке вопроса — «большое количество VST», да, не успевает наполнится буфер из-за недостаточных ресурсов компьютера, где надо выискивать слабое звено: процессор, память (жесткий диск обычно реже бывает виновником). Тут только увеличивать буфер.

Если копать очень глубоко, то может быть виноват драйвер, работающий мостом, аналогично ASIO4All. Еще причиной тормозов может быть использование USB карты вместо PCI/PCIe.
Ко всему вышеперечисленному предлагаю также перейти на 64-битные VST и хост, т.к. а) возможно более эффективное использование cpu б) больше памяти под VST (тот же KONTAKT, например, будет квакать, если ему выделить недостаточно памяти под сэмплы даже на топовой машине).
Ещё часто причиной треска становится занятие DPC, очень часто драйверовм WiFi карт. Пока обрабатываются отложенные процедуры, драйвер звуковой карты не может пополнить буфер на отправку.
Jack
Для качественного воспроизведения достаточно ALSA.
Пост в первую очередь о профессиональном звуке вроде как. ALSA тут явно не достаточно.

Ну и тут речь совсем не о качестве. Для качества ASIO явно перебор.
А разницу в ресемплированном звуке c 44кгц до 48кгц (да даже наоборот), пущенному по двум ржавым металлическим вешалкам и по золотому кабелю за $20к, на слух вы заметите только в 2 случаях — эффект плацебо, или же имплантированный в мозг АЦП. Что бы там не говорили аудиофилы.
Опрос подразумевает пользователей Windows, задумываются ли они о качестве.

Касаемо Линукс, уместно будет «Как-то играет и нормально», т.к. платформа или мало привлекает ценителей качественного звука, или потребность в звуке у пользователя Linux далеко не на первом месте.
Если кто с этим не согласен, то:
1. Нет тестов звуковой системы
2. Ограниченное количество звуковых карт, способных работать под Linux
3. Софт для работы со звуком в зачаточном состоянии…
Для фанатов линукса и «минусеров».

Если хочется доказать, что Linux годен для высококачественного звука, приветите тесты на побитовость выдачи данных со звуковых карт, включая корректную работы автомата опорной частоты. Если таких тестов нет, то могу провести соответствующий тест, но для этого нужен любитель линукса, который сможет в Москве в Soundpal подъехать с компьютером с установленным Linux и звуковой картой с цифровым выходом. Я проведу тест на «Bit Perfect» с помощью Audiolab M-DAC. Процесс можно сфотографировать и сделать материал в виде «как правильно настроить Linux»…

Пока что внятных тестов нет, кроме фанатичной веры в идеальность Linux…
Вывод bit perfect звука через ALSA (без PulseAudio) в Linux — проще простого, буквально выбрать устройство карты, а не dmix, в аудиоплеере. Насколько я знаю, существуют специальные аудиофильские железные плееры с Linux, которые выводят bit perfect аудио, и даже есть какие-то специальные дистрибутивы для Raspberry Pi.
C PulseAudio все немного сложнее, но, как минимум, выбор опорной частоты в нем реализован.

У меня, к сожалению, в лаптопе цифровое аудио только на DisplayPort. Если вы предоставите DisplayPort → S/PDIF переходник, USB-аудиокарту или просто компьютер с цифровым выходом, можно потестировать. В Москве буду 26-27 числа.
DisplayPort → S/PDIF — такого нет.
Компьютеры к сожалению «рабочие», на них не поэкспериментировать.
Рабочие компьютеры выключать нельзя? Linux с флешки загрузим, никакие данные на HDD не изменятся. Ну, или с лаптопа, USB-аудиокарты-то у вас найдутся, я уверен.
Загрузится система уже с установленным аудиоплеером от Linux?
Конечно.
Если так, то Bit-Prefect можно будет проверить напрямую по шине USB в нем самом. По отношению к Windows M-DAC обычным PnP — результат будет типичен для большинства USB-DAC.
Сейчас еще люди, которые работают на яблочной оси подтянутся, их CoreAudio определения «как-то играет» явно не заслуживает.
Возможно, имело смысл сделать более явный заголовок на тему Windows-only?

P.S. насчет пункта 2 — у меня Windows не видит сама по себе мою ESI juli@, а Linux четко определяет устройство по чипу ICE-чего-то-там и вполне себе играет из коробки. Я это к тому, что не слышал от знакомых о проблемах со звуком на линукс-машинах. Обычно — поставил — заиграло. Можно поподробнее на тему проблемных звуковых карт? Есть мысли поменять карту на внешнюю и, возможно, такая информация, поможет лично мне не сделать Большую Ошибку.
Сюрпризы бывают) Я вот несколько месяцев назад словил эпичный баг ядра, который пофиксили после моего баг-репорта в 3.19. Я писал о нем: Как драйвер Windows коварно ломает звук в Linux или мучительные поиски бага
3. Софт для работы со звуком в зачаточном состоянии…
Под Линукс есть Bitwig.
Bitwig с каким секвенсором по своим возможностям равноправно сопоставим? С какой версией CuBase, Logic, Sonar и т.п.? Насколько он современен?
Я не знаю людей, которые бы достаточно хорошо разбирались одновременно в Bitwig-е и в перечисленных вами программах. Могу порекомендовать скачать демку и составить своё мнение.

Редактор MIDI весьма удобный. Из форматов озвучки поддерживает, как минимум, VST, SF2 и ещё собственный формат.
В материале максимально подробно расписано, в каких случаях не стоит рассчитывать на передачу «бит-в-бит» независимо от платформы. Есть ли в Core-Audio настройка, эквивалентная WASAPI?

Что касается, «как-то играет» в MAC, то это будет третий или четвертый пункт. К сожалению, тестов на качество не намного больше, чем на линукс. Но доверия больше, т.к. ОС активно используется в коммерческих проектах, есть шанс, что уделено должное внимание звуковой части.

Было бы интересно узнать, какие плееры в MAC реально работают в монопольном режиме (при воспроизведении из которых уже нет никаких звуков от других программ).

В Linux от звуковой части нужно лишь что бы просто был звук, аналогично режиму PnP в Windows. Отсюда и «хорошо работают», аналогично PnP картам под Windows. Проф. карты имеют множество нестандартных настроек и для раскрытия полной функциональности зачастую нужен отдельный драйвер.

Конкретно под Linux сложно что-то посоветовать, т.к. нет под него отдельного компа или жесткой необходимости в Linux.

Конкретно под Linux сложно что-то посоветовать, т.к. нет под него отдельного компа или жесткой необходимости в Linux.
То есть Вы понятия не имеете о фактической ситуации в Linux или MacOS и строите свои умозаключения лишь на экстраполяции опыта работы с Windows и популярности этих систем среди Ваших знакомых. Всё понятно.
Я достаточно внимательно слежу за развитием звуковых карт на альтернативных платформах. Временами кто-то сидит на линуксе и задает вопрос, а насколько там все хорошо со звуком? Но не имеет возможности сделать измерения или проверку, т.к. для теста по косвенным показателям нужен второй компьютер. Второго компьютера с адекватным интерфейсом как правило ни у кого нет. Итог — обмен впечатлениями «на слух».

У вас есть ссылки на объективные технические тесты, где было бы указано, такая сборка ОС, такая-то звуковая, воспроизвелось из такой-то программы, запись на такое-то устройство и как итог сравнение воспроизведенного и записанного файла, где данные соответствуют «бит-в-бит»?

Основы звуковой подсистемы ОС мало чем отличаются от основ секвенсора и проблемы и решения однотипны.
У вас есть ссылки на объективные технические тесты
У меня нет. Но я и не делаю голословных заявлений.
Основы звуковой подсистемы ОС мало чем отличаются от основ секвенсора и проблемы и решения однотипны.
А вот это неправда, в Linux, например, нет особой необходимости в ASIO, тракт и так достаточно гибко конфигурируем, чтобы получить низкую задержку.
Вы голословно утверждаете, что оппонент не прав, фактов своей точки зрения нет, но пусть оппонент попытается доказать обратное, ведь пока он не доказал обратное, он вроде как не прав.

У меня складывается впечатление, что Вы вероятно материал прочитали по диагонали и возмущаетесь, что линукс не назван лучшей системой для аудиофилов. В материале подробно рассказано, в чем отличие ASIO от специального режима WASAPI.

Вы можете привести пример сравнения минимальных задержек из под секвенсора в Linux c аналогичным проектом под Windows с ASIO и отдельно WASAPI, что бы утверждать, что Linux достаточно продвинут своими штатными настройками?

Вы голословно утверждаете, что оппонент не прав
Я вполне обоснованно утверждаю, что Ваши утверждения голословны, не более. Дискуссии здесь не получится, т.к. Вы балабол.
Простая логика. Звуковая подсистема в Linux изначально расчитанна только на прямой доступ приложения к звуковой карте и сможет воспроизводить звук лишь то приложение, которое первое захватит звуковую карту. Чтобы иметь возможность слушать сразу несколько приложений, требуется установка дополнительных модулей для передескретизации и микширования. То есть без дополнительных настроек звуковая подсистема Linux работает в режиме полностью аналогичном ASIO из Windows с любым драйвером звуковой карты, иначе просто не умеет.

Разумеется, в user-friendly дистрибутивах уже из коробки установлены и настроены все необходимые модули (плагин dmix для alsa и/или звуковой сервер pulseaudio, работающий поверх alsa — pulseaudio захватывает звуковую карту монопольно, однако все приложения выводят звук через него и он осуществляет микширование), чтобы пользователи не испытывали проблем, но их легко отключить.
Теория хороша, когда подтверждается практикой. В теории в Linux все хорошо, но так же хорошо, как и в остальных ОС, в которых на практике выявляются проблемы. Практических проверок в Linux не было. Можно минусить любые подозрения, что в Linux могут быть проблемы, но лучше от этого Linux работать не будет. И мало кто из поклонников Linux готов дать реальную гарантию своим словам. Например выплатить N-ую сумму денег, если при логически правильных настройках не будет никакого «бит-в-бит». У меня например есть фактические доказательства работы режима WASAPI в Windows и соответственно могу ответить за свои слова. Про Linux же есть только теория и ничего более.

Уровень утверждений, независимо от логичности — на «авось», как бы это обидно не было.
Можно сравнивать звуковую подсистему Linux с электромобилем. Он экологически чист by design (а звуковая подсистема Linux bit perfect by design). Можно, конечно засунуть в багажник дизельный генератор и экологией не будет пахнуть и близко (зато получится огромный бонус в виде увеличения дальности пробега во много раз, а в случае звуковой подсистемы — можно будет слушать сразу несколько источников). Более того, есть производители электромобилей, которые ставят дополнительный двигатель прямо на заводе и называют такие автомобили гибридными (поскольку микширование нужно большинству пользователей, нужные настройки сделаны по умолчанию в большинстве дистрибутивов). Однако владелец машины всегда может легко (скорее всего простым нажатием кнопки в салоне) отключить неэкологичный двигатель и ехать на аккумуляторах, а вот владельцу авто только с ДВС придётся вносить значительные изменения в конструкцию.
Про Линукс: если мы говорим об аудиофилах (любят аудио), а не профессионалах (редактируют аудио), то им просто не нужны возможности карты, кроме как качественный ЦАП.

Если говорить про мою juli@, она корректно определяется системой, далее тривиальными настройками самого плеера, точнее ALSA, настраивается отключение микширования, задается вывод звука в конкретное устройство (о чем говорит и ValdikSS). Этого должно быть достаточно для получения bit perfect output.

Это я к чему: если смотреть на работу со звуком с колокольни звукорежиссера, допускаю, что Вы правы и весь потенциал карты как то хардварный midi из карты выжать тяжелее (никогда не интересовался). В случае же простого прослушивания звука, честно говоря, не вижу, что может напороть звуковая система Linux, в которой явно можно отключить микширование и указать частоту дискретизации. Лично аппаратное тестирование не проводил, но в сети находится просто ведро описаний как настроить bit perfect в Linux.

Другими словами, то, что для Windows решается установкой ASIO, в Linux решается настройками — поэтому ASIO там не нужно. (Несколько лет назад сдуру пытался найти ASIO для своей карточки под Linux, когда съезжал с Windows. Не найдя, пришлось разбираться в вопросе)
Карты разные бывают, например там 20 каналов на выход, как их конфигурировать под 5.1 штатными настройками? Или выставление клока внутренний/внешний? Или переключение чувствительности входов/выходов? Тут и приходится городить отдельный драйвер и ограничиваться только теми ОС, под которые по мнению производителя и будут раскупаться звуковые карты.

Под простой стерео USB-ЦАП никаких настроек обычно не нужно и тут достаточно только штатных настроек.
Продвинутая разводка каналов есть во всех программах (ALSA, PulseAudio, JACK).

Звуковая карта при опросе выдаёт все свои настройки. Драйверу всё равно, как они называются — громкость, переключатель клоков, и т. д. — это уже забота пользователя. В качестве «отдельного драйвера» тут выступает текстовый файл настройки.
Я не видел готовых текстовых файлов под серьезные проф. звуковые карты, например к E-MU1616m, использующий еще и аппаратный процессор с гибкой маршрутизацией каналов и эффектами. Опрос драйвера скорее всего даст тонну настроек и вместо того, что бы сразу приступить к работе, надо потратить пару месяцев на написание драйвера самостоятельно. И хорошо если пару месяцев, а не больше…

Если это исключительно забота пользователя, то чем тогда должен заниматься пользователь, конкретными задачами или настройкой ОС под задачи? Пользователь просто выберет другую ОС.

Это все не к тому, что плохо или хорошо, а к тому, что без внятной готовой панели управления, «сложные» карты неработоспособны.
Я не видел готовых текстовых файлов под серьезные проф. звуковые карты
А какие видели? :) Можно найти полно примеров сложных настроек для продвинутых карт. На всякий случай предостерегу от подробного изучения этих конфигов; чтение документации на первом этапе гораздо рациональнее.

Если это исключительно забота пользователя, то чем тогда должен заниматься пользователь, конкретными задачами или настройкой ОС под задачи? Пользователь просто выберет другую ОС.
Странно слышать это от человека, рассуждающего о профессиональной обработке звука. Да, ручное написание конфигов не так удобно, как клики по галочкам в окошке, но это — мощный инструмент, позволяющий решить любые задачи и обойти любые проблемы. Месяц на изучение нужно потратить только один раз, зато потом любая карта будет делать именно то, что вы от неё хотите, и вы всегда будете уверены, что выжали из неё возможный максимум.
Если не брать программистов, у которых программирование — это прямая работа, то все остальные делятся на три группы. Для одной группы — это хобби/увлечение, для второй — альтернатива получить программу «бесплатно/дешевле», вместо покупки дорогостоящего готового решения и третья группа — когда нужной программы нет ни за какие деньги и приходится программировать от безысходности.

Программирование Reference Audio Analyzer на C# с попутным изучением C# заняло более 4 лет, а программировать пришлось из отсутствия готовых решений. Если потраченное время на программирование вывести в непрерывный отрезок (5 полноценных дней в неделю), это будет где-то полгода.

Если бы для тестов существовало уже готовое решение, то эти полгода потратились непосредственно на тесты, и протестировано было бы вдвое или трое больше моделей наушников, усилителей и звуковых карт. А так время уходит не на тесты, а на создание инструмента для тестов.

Аналогичная ситуация и с Linux, пользователю необходимо сперва потратить время на «программирование» ОС под свои задачи, вместо того, что бы сразу приступить к выполнению своих задач. А для профессионалов выполнение задач — это заработок и тут «время=деньги». Тем, для кого программирование не является увлечением, намного проще купить ОС, которую не надо программировать.
НЛО прилетело и опубликовало эту надпись здесь
насчёт задержки: насколько я понял, когда изучал вопрос по диагонали, важна не столько низкая задержка, сколько постоянная и низкая. впрочем, скорее всего я ошибаюсь, мой опыт ограничен игрой на миди-клаве с софт-синтом без обработки
Не думаю, что однократная задержка в 20 мс испортит запись, однако профессиональные звукачи-линуксоиды устанавливают realtime-ядро, чтобы никакой фоновый процесс не отвлекал процессор от обработки звука.
Для комфортной игры используют буфер не более 192/256 семплов. Это 5 мс при частоте дискретизации 44100 кГц. Сверху еще добавляется 1-2 мс на преобразование в ЦАП (работу цифрового фильтра).

Для обычной записи без управления эффектами или игрой на виртуальных инструментах низкая задержка не принципиальна.
Для обычной записи без управления эффектами или игрой на виртуальных инструментах низкая задержка не принципиальна.
Но при записи с метрономом может потребоваться компенсация задержки.
Если ведется мониторинг сигнала проходящего через АЦП/ЦАП с обработкой, то безусловно, низкая задержка обязательна.

Из USB карт выжать низкую задержку сложнее и производители стараются предусмотреть опцию «Direct Monitoring», пуская сигнал с входа на выход напрямик.
Вопрос от нуба
А причем тут внешний ЦАП, 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 и их ядерные драйверы - код там, мягко говоря, странный.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий