Нет, это теория+практика, а вот это вот -
Даже не знаю как назвать. Точно? Без задержки?
Low latency plugins
- Автор темы K.N.N.
- Дата начала
@Aleksandr Oleynik, На слух я не ощутил, программами не тестировал ещё) Какие условия нужно создать, чтоб глобальная задержка была 0мс, а на слух я услышал задержку?
Сделал тест с 5ю дорожками, на каждой по синтезатору, и по 100 компрессоров в последовательной цепи...Пока CPU не перегрузил, всё работает без каких-либо задержек и нареканий. Я не знаю, какие нужны условия, чтоб создать задержку плагинами с нулевой задержкой... Пока ничего внятного я не услышал.
Вы не не услышали, а не поняли. Но я пока не знаю как ещё пояснять...
Ну и скриншот с 0 ms - это смешно.
Я не разбираюсь в настройках Студио Ван, но сдаётся мне, что у вас таки включен аналог Асио Гарда.
Нужно попросить @Zerocool -а посмотреть, он знает Студио Ван.
У вас на всех дорожках включена запись и мониторинг? Вроде сигнал на треках видно и плей не включён, значит миди на входе от внешней клавы....
На сколько я знаю, Студио Ван вообще плохо работает с мониторингом при записи - у неё вся обработка записываемых треков идет через одно ядро процессора и ваш буфер сразу захлебнётся. А все ваши картинки с тестами, скорее всего, вообще на плейбеке и тогда не ясно какую задержку вы там слушаете, ну или какой то один трек в записи.
Последнее редактирование:
Что смешного?
Общая задержка плагинов равна ноль миллисекунд, с оговоркой на буфер DAW, который в данном случае составляет 64 семпла+ хвостовой буфер звуковой карты. То есть в пределах общей задержки: DAW+ Звуковуха, это количество плагинов не добавляет никакой дополнительной задержки, а просчитывается за этот самый буфер, пока не упрется в производительность RT CPU. Дальше либо треск и дропы, либо увеличение буфера.мониторинг включён на всех, этого достаточно.
Это не так, вся обработка нормально и даже очень обрабатывается всеми ядрами процессора. В Studio One плохо реализован только LLM, который нахрен в данном случае не сдался @Константин Викторович.
Не включен, судя по его картинкам выше.
@Radiator, Вот почему ты меня понимаешь а @Aleksandr Oleynik, не очень?)))
@Aleksandr Oleynik, Нет у меня там никакого асио гуарда, ещё раз повторюсь, я не пользуюсь этим костылём, и прекрасно знаю и понимаю как оно работает. Это чистый костыль который реализован на удивление крайне не удобно. Де факто, если плагин мне репортит о том, что он зеро летанси, то я это получаю именно на практике, заваливая проект им, и до тех пор, пока центральный процессор держит проект, всё работает без каких -либо задержке. Задержек нет ни при мониторинга миди, играя клавой через контакт или какой-либо синт, ни при аудио мониторинге, я могу петь с включенными обработками и использовать внутренний роутинг. Честно, я очень хочу разобрать о каких задержках Вы пытаетесь донести, а именно, где они вообще фиксируются, как они проявятся, и как с этим жить потом))) Но пока, работает всё чётко. Соответственно, мой раннее заданный вопрос, о списке плагинов, которые официально супортят 0мс летенси, актуален! К примеру стандартные плаги с-1, позволяют вообще забыть про асио гуард, за исключением настроек с включенным "лукахэдом".
@Aleksandr Oleynik, Нет у меня там никакого асио гуарда, ещё раз повторюсь, я не пользуюсь этим костылём, и прекрасно знаю и понимаю как оно работает. Это чистый костыль который реализован на удивление крайне не удобно. Де факто, если плагин мне репортит о том, что он зеро летанси, то я это получаю именно на практике, заваливая проект им, и до тех пор, пока центральный процессор держит проект, всё работает без каких -либо задержке. Задержек нет ни при мониторинга миди, играя клавой через контакт или какой-либо синт, ни при аудио мониторинге, я могу петь с включенными обработками и использовать внутренний роутинг. Честно, я очень хочу разобрать о каких задержках Вы пытаетесь донести, а именно, где они вообще фиксируются, как они проявятся, и как с этим жить потом))) Но пока, работает всё чётко. Соответственно, мой раннее заданный вопрос, о списке плагинов, которые официально супортят 0мс летенси, актуален! К примеру стандартные плаги с-1, позволяют вообще забыть про асио гуард, за исключением настроек с включенным "лукахэдом".
Всё до боли просто на самом деле. Сейчас объясню. Глобальная задержка в с-1 это вот этот мониторчик, который я вам заскринил. Почему глобальный, а потому что если повесить 2 плагина с 2мс задержкой последовательно, будет глобальная задержка, равная 4мс! Но! Если повесить эти 2 плагина на разные дорожки, глобальная задержка будет 2мс! Я сам это недавно узнал, и сильно удивился... Так что глобальная задержка, и мониторинг фрагментарных задержек, по общей сумме всегда будут показывать разные цифры.
Да по с-1 всё предельно понятно, ясно и очевидно... Я понять не могу, про какую ещё скрытую задержку говорите Вы, если я её ни на ощупь не могу найти, ни документально?
Я не про скрытую задержку говорю, я говорю о том, что выбирать плагины для работы в Рипол тайме, нужно не только по отсутствию у них своей задержки, а и по времени обработки их алгоритмов.
Вы набросали в проект простеньких, не жручих компрессоров и они не захрипели и не заставили вас увеличить Буфер АСИО и соответственно общую задержку.
А если вы в самом деле создадите большой проект, вы же с этого и начали -
То не задержка плагинов вам даст доп. буфер, а их прожорливость ОБЩАЯ заставит поднять АСИО Буфер.
Глобальной называется ОБЩАЯ задержка всего этапа - вход/выход - roundtrip.
@Aleksandr Oleynik, Тогда вопрос возникает: Какие плагины заставят переполнить асио буфер раньше, чем CPU, имея декларируемый статус зеро летанси? Давайте проводить тест. Из того, что у меня есть (правда есть у меня не много), ни один плагин так себя не повёл... CPU быстрее перегружается чем асио.
Вся проблема в том, что это нигде не декларируется, и перед покупкой желательно знать этот момент. Потому что я лично, хочу перейти как раз, как Вы называете "Рипол тайм", и не заморачиваться больше с какими-то задержками, асио гуардами, и мониторингом через внешние присоски.
Александр, я тоже прям в удивлении - то есть по вашему для загруженного реалтайма не за задержками надо гнаться- а выстроить свою цепочку ( сминималтными задержками у плагов, не обязательно нулевыми) - и уже прсле смотреть , не валят ли они проект при активированных на запись и мониторинг нужных дорогах?
А если коротко то только проверка боем показательна?
Да эта каша в голове у большинства....
Даже если судить по этой ветке....
Я уже пообещал СЕБЕ, что сделаю понятный мультик, в котором будут короткие серии по всем этим вопросам.
Вот только со временем, не смотря на карантин, у меня сейчас туго....
ОК. Попробую ещё раз пояснить по той схеме, которую хочу использовать в мультике.
Заодно поймём все вместе - понятно ЭТО или опять НЕТ!
Тест будет несколько утрированным, но не бессмысленным.
Частота дискретизации 192 kHz.
Гитарный плагин Neural DSP Abasi
Смотрим на его перформанс в докторе -
В режиме Normal у него НУЛЕВОЙ собственный буфер (не путать с задержкой и объясню почему в который раз!).
Т.е. плагину не нужен дополнительный буфер для каких то своих целей типа лукахеда.
Так вот плагин будет сообщать DAW о том, что его задержка = 0 ms -
- PDC у него 0 ms.
Но на графике Перформанс выше прекрасно видно, что время, которое нужно плагину для его алгоритма совершенно не 0 ms -
А точнее (при 192 kHz) - на 16384 сэмплах буфере у него будет 253.38760 ms время обработки.
Т.е. если мы поставим 64 spl буфер, получим время обработки 0,98 ms.
Но при 192 kHz - 64 сэмпла буфере это время = 0,33 ms (64/192=0,33).
И ЧТО ЭТО ЗНАЧИТ?
А то, что ЭТОТ плагин, при том, что буфер ему доп не нужен и в DAW он сообщает "типа задержку" = 0 ms -
НЕ БУДЕТ работать в Риал Тайме на 192 kHz!
Основное, что нужно понять, что Плагин с нулевой собственной задержкой не обозначает, что у него алгоритм умеет считать данные за 0 мс. Это означает, что алгоритм должен справится за время меньшее, чем вы поставите АСИО буфер и что дополнительного буфера Плагину Не Нужно.
И вот демонстрация того, что это ТАК в DAW -
При том, что процессор занят АЖ на 5,4% - ASIO средний показывает = 88,3% НО!!! Пиковый видим в виде левой цифры в дроби -
1,62ms/0,33ms - правая цифра это выставленный буфер в ms - 192/64=0,33 ms
левая цифра это пиковое значение времени обработки сигнала ПЛАГИНОМ = 1,62 ms -- Т.е. пиковое потребление = 490%
И оно отличается от того, что намерял PluginDoctor, там у нас получилось 0,98ms (смотри выше). Почему?
А потому что кроме времени нужного плагину на его алгоритм есть ещё накладные расходы - время для кучи другого что нужно, чтоб данные попали в плагин и из него вышли и прошли по всем цепочкам самой DAW!
Очень надеюсь, что после прочтения ЭТОГО всё станет ясно.
Надеюсь на фидбэк.
Заодно поймём все вместе - понятно ЭТО или опять НЕТ!
Тест будет несколько утрированным, но не бессмысленным.
Частота дискретизации 192 kHz.
Гитарный плагин Neural DSP Abasi
Смотрим на его перформанс в докторе -
Т.е. плагину не нужен дополнительный буфер для каких то своих целей типа лукахеда.
Так вот плагин будет сообщать DAW о том, что его задержка = 0 ms -
Но на графике Перформанс выше прекрасно видно, что время, которое нужно плагину для его алгоритма совершенно не 0 ms -
А точнее (при 192 kHz) - на 16384 сэмплах буфере у него будет 253.38760 ms время обработки.
Т.е. если мы поставим 64 spl буфер, получим время обработки 0,98 ms.
Но при 192 kHz - 64 сэмпла буфере это время = 0,33 ms (64/192=0,33).
И ЧТО ЭТО ЗНАЧИТ?
А то, что ЭТОТ плагин, при том, что буфер ему доп не нужен и в DAW он сообщает "типа задержку" = 0 ms -
НЕ БУДЕТ работать в Риал Тайме на 192 kHz!
Основное, что нужно понять, что Плагин с нулевой собственной задержкой не обозначает, что у него алгоритм умеет считать данные за 0 мс. Это означает, что алгоритм должен справится за время меньшее, чем вы поставите АСИО буфер и что дополнительного буфера Плагину Не Нужно.
И вот демонстрация того, что это ТАК в DAW -
При том, что процессор занят АЖ на 5,4% - ASIO средний показывает = 88,3% НО!!! Пиковый видим в виде левой цифры в дроби -
1,62ms/0,33ms - правая цифра это выставленный буфер в ms - 192/64=0,33 ms
левая цифра это пиковое значение времени обработки сигнала ПЛАГИНОМ = 1,62 ms -- Т.е. пиковое потребление = 490%
И оно отличается от того, что намерял PluginDoctor, там у нас получилось 0,98ms (смотри выше). Почему?
А потому что кроме времени нужного плагину на его алгоритм есть ещё накладные расходы - время для кучи другого что нужно, чтоб данные попали в плагин и из него вышли и прошли по всем цепочкам самой DAW!
Очень надеюсь, что после прочтения ЭТОГО всё станет ясно.
Надеюсь на фидбэк.
Последнее редактирование:
@Aleksandr Oleynik,
Всё зупа гут понятно, и раньше было понятно.
Вот только у rt longest block значения скачут.
Иногда устаканиваются, а иногда и нет. Проблема может скрываться в конкретных плагинах или в дровах системы, я правильно понимаю?
Всё зупа гут понятно, и раньше было понятно.
Вот только у rt longest block значения скачут.
Иногда устаканиваются, а иногда и нет. Проблема может скрываться в конкретных плагинах или в дровах системы, я правильно понимаю?
hold (в скобках от дроби справа) включите и не будет скакать.
Если включён холд - будет показывать максимальное значение за период между ресетами графика, если не включен - будет показывать (скакать) моментальное значение, а оно меняется.
Не даёт объективно оценивать ситуацию. В проекте ничего не меняю.
На мониторинге один track.
Единственное, что делаю, включаю и выключаю режим холд.
Сперва он мне показывает 9ms/2.9(hold), затем 2.73ms/2.9(hold)
ничего не хрипело в обоих случаях. (да, Защитник Васио был включён)
@Aleksandr Oleynik, Получается, что если я выставляю буфер карты, скажем 64 сэмпла, у меня это порядка 5мс, то пока проект не трещит, это означает что вся моя сумма задержек не достигает 5мс?
правильнее это называть временем обработки буфера
Если внимательнее читать, что написано уже до
И здесь
То можно было и не развивать дальше эту тему, но Александр почему-то посчитал, что
Такая петрущка везде, где присутствует цифровая обработка сигналов, ибо вот это
Неотъемлемая часть процесса обработки.
Просто нужно понять, что CPU, DSP, FPGA и т д, могут обработать какое-то количество конкретно взятых плагинов за конкретное время, и если это время превысит лимит отведенный буфером (или как правильнее "время обработки буфера"), то значит увеличиваем буфер. У нативных (CPU) систем это делается просто увеличением буфера DAW, у DSP c этим жестко, они могут обработать только фиксированное количество конкретно взятых алгоритмов.
Последнее редактирование:
Да)Наконец то Константин Вы Поняли) А Вы знаете,что даже без компьютеров всяких у миди есть задержка в 6 миллисекунд?)На Железе)
Чем мощнее проц, тем соответственно больше плагинов можно задействовать на этом "времени обработки буфера" Думаю это вообще очевидно.
Какой нить супер пупер алгоритм, типа новых гитарных приблуд/симуляторов могут положить современный проц на чд в 192кгц в одном экземпляре, на буфере пригодном для мониторинга в реальном времени.
Когда всё разжёвано и в рот положенно, то можно и не развивать.
Если вам моё развитие показалось излишним, просто не читайте его. Я же посчитал необходимым ещё раз всё объяснить.
Вот прям читаем это -
И понимаем - всем всё понятно....