Как узнать задержку звуковой карты
Обновлено: 06.07.2024
В этом примере показано, как измерить задержку аудио устройства. Пример использует audioLatencyMeasurementExampleApp, который в свою очередь использует audioPlayerRecorder наряду с тестовым сигналом и взаимной корреляцией, чтобы определить задержку. Чтобы избежать интерференции доступа к диску, тестовый сигнал загружается в dsp.AsyncBuffer object сначала, и системы координат передаются потоком от того объекта до аудио устройства.
Введение
В общих чертах задержка задана как время от того, когда звуковой сигнал вводит систему, пока это не выходит. В цепи обработки цифрового аудио существует несколько параметров, которые вызывают задержку:
Оборудование (включая A/D и преобразование D/A)
Драйверы аудио, которые связываются со звуковой картой системы
Выборки на систему координат (buffer size)
Алгоритмическая задержка (e.g. задержка введена фильтром или звуковым эффектом),
В этом примере показано, как измерить задержку цикла обработки. Таким образом, задержка подверглась при проигрывании аудио через устройство цикличное выполнение поддерживает аудио физическим петлевым кабелем и запись петлевого аудио с тем же аудио устройством. Для того, чтобы вычислить задержку для вашего собственного аудио устройства, необходимо соединить аудио и аудио в портах с помощью петлевого кабеля.
Задержка туда и обратно не ломает измерение между выходной задержкой и вводить задержку. Это измеряет только совместное воздействие двух. Кроме того, наиболее практические применения не будут использовать петлевую настройку. Обычно цепь обработки состоит из записи аудио, обработки его и проигрывания обработанного аудио. Однако включенная задержка должна быть тем же самым, так или иначе обеспечил другие факторы (формат кадра, частота дискретизации, задержка алгоритма) не изменяются.
Аппаратная задержка
Меньшие форматы кадра и более высокие частоты дискретизации уменьшают задержку туда и обратно. Однако компромисс является более высоким шансом уволенных, происходящих (переполнения/недогрузки).
В дополнение к потенциально увеличивающейся задержке объем обработки вовлеченного в аудио алгоритм может также вызвать уволенных.
Измерение Задержки с audioLatencyMeasurementExampleApp.m
Функция audioLatencyMeasurementExampleApp вычисляет задержку туда и обратно в миллисекундах для данной настройки. Переполнения и недогрузки также представлены. Если переполнения/недогрузки не являются нулем, результаты, вероятно, недопустимы. Например:
Некоторые советы при измерении задержки
Обработка в режиме реального времени в операционной системе общего назначения только возможна, если вы минимизируете другие задачи, выполняемые компьютером. Этому рекомендуют:
Закройте все другие программы
Гарантируйте, что никакие недогрузки/переполнения не происходят
Используйте достаточно большой buffer size (SamplesPerFrame), чтобы гарантировать сопоставимое поведение без уволенных
Гарантируйте, что ваши аппаратные настройки (buffer size, частота дискретизации) совпадают с входными параметрами к measureLatency
На Windows можно использовать функцию asiosettings, чтобы запустить диалоговое окно, чтобы управлять аппаратными настройками. На macOS необходимо запустить Аудио Setup MIDI.
При использовании ASIO (или CoreAudio с Mac OS), измерения задержки сопоставимы, пока никакие уволенные не происходят. Для небольших буферных размеров возможно получить чистое измерение в одном экземпляре и уволенных следующее. Опция Ntrials может использоваться, чтобы гарантировать сопоставимое поведение уволенного при измерении задержки. Например, чтобы выполнить 3 измерения, используйте:
Измерения для различных буферных размеров
На macOS также возможно попробовать различные форматы кадра, не изменяя аппаратные настройки. Чтобы сделать это удобным, можно задать вектор из SamplesPerFrame:
Оригинал материалов для этого поста можно найти в следующей статье:
Я не стану прямо переводить, но постараюсь кратко и понятно изложить русским языком все что вам нужно о цифровой задержке в музыке.
Много картинок не ждите, ждите много текста, и помните у птиц беда с пунктуацией.
В английском языке слова Latency и Delay на русский переводятся одинаково, и означают задержку. Хотя latency в основном употребляют, когда говорят об аудио задержке. Под аудио задержкой понимают промежуток времени между тем как звук был извлечен и тем моментом в который он попал к вам в уши. Обычно задержка измеряется в миллисекундах (мс).
Если говорить о природной/физической задержке, то вот её пример: Представьте что сидите за пианино и хотите извлечь звук нажатием его клавиши. Что произойдет когда вы её нажмете? Ваш палец нажимает на клавишу, клавиша приводит в движение молоток, молоток бьет по струне, звук от струны путешествует к вашим ушам. Вот промежуток между тем как вы нажали на клавишу и тем как вы услышали ноту и есть задержка.
Эхо - также является природной задержкой звука, с ним чуть посложнее поскольку вы слышите и "исходный" сигнал и задержанный. Ученые, проведя опыты, подсчитали, что задержка менее
10 мс не воспринимается человеческим ухом. В промежутке между 12 и 15 мс вы начнете "чувствовать" эффект задержанного сигнала, и только задержка от 20мс заставит ваш мозг разделить между собой исходный и задержанный сигнал.
Теперь подойдем к цифровой записи, представим что мы пишем злой такой, мощный соляк, на компьютере. В аудиостанции(аудиохост, DAW) играет минусовка, стучит метроном, гитара подключена к интерфейсу и включен мониторинг (прослушка) сигнала через аудиостанцию. Но вот беда, мы играем как будто с каким то эхом, звук который мы слышим сильно запаздывает от наших пальцев, как правило исполнителя это сильно дизориентирует и записать партию в таких условиях практически невозможно. Мы кидаемся к настройкам нашего аудио интерфейса, видим загадочное значение какого то буфера в 128 семплов, и подпись в 2.9 мс задержки.
Но постойте, стоя на сцене в метре от усилителя, при скорости звука 340 м/с, мы будем слышать наш звук с задержкой минимум 3мс! Так почему на сцене 3 мс мы не замечаем, а в студии 2.9 мешают нам нормально работать?
Все не так как кажется
Для того чтобы разобраться в проблеме нам нужно несколько углубится в физику процесса и разобрать, каким именно образом звук путешествует у нас в компьютере.
Мы начинаем с того момента как звук нашей гитары или вокала например, оказывается на аналоговых входах нашего интерфейса.
Далее наш сигнал попадает в аналого-цифровой преобразователь (АЦП) аудио интерфейса, который занимается тем что преобразовывает непрерывную звуковую волну в массив битов и байтов. Процесс невероятно сложен, но занимает немногим более половины миллисекунды. Забегая вперед скажу,что на другом конце всей этой цепочки звук будет поступать на цифро-аналоговый преобразователь вашего интерфейса (ЦАП), который в свою очередь будет преобразовывать дискретный сигнал в электрические импульсы, для того чтобы вы могли услышать его на своих динамиках или наушниках. Ещё пол миллисекунды или типа того.
Далее за дело берется ваш ASIO (в случае windows) или CoreAudio (Mac) драйвер. Он осуществляет "доставку" сигнала со входа USB в ваш аудиохост и обратно.
Все это "расстояние" сигнал преодолевает путешествуя из одного буфера в другой.
Буфер - это участок компьютерной памяти, выделенный для временного хранения данных, пока те двигаются с одного места на другое. Всего в нашей цепочке четыре вида таких буферов.
*Выходной буфер ASIO драйвера
*Выходной буфер USB шины
Здесь нам придется ещё раз прерваться, и кратко объяснить зачем вообще эти буферы нужны.
Зачем нужны буферы
Дело в том что "многозадачность" компьютера это всего лишь иллюзия, процессор в один момент времени работает только с какой-то одной задачей, но за счет того что он очень (ОЧЕНЬ) быстро переключается между ними, выполняя то часть одной, то часть другой, кажется что процессы протекают одновременно.
В нашем случае процессор по большей части выполняет задачу по переносу данных с нашего интерфейса в аудиостанцию, и обратно. Так как он не может постоянно этим заниматься, он делает это кусками. Отправил кусок, занялся делом, ещё отправил кусок, ещё чем то занялся. Чем больше размер буфера, тем больше мы можем позволить процессору тратить времени на системные задачи, но вместе с тем мы будем задерживать сигнал. Чем буфер меньше, тем ближе к "реальному времени" будут выполнятся задачи, но это может отрицательно сказаться на стабильности всей системы. А кто, спросите вы, устанавливает размер этих буферов? -драйверы, поговорим о них!
ASIO и CoreAudio драйверы
Ни одно устройство просто так работать с вашим ПК не будет, для него необходим драйвер. Драйвер это специальная программа которая позволяет другим программам на вашем компьютере "общаться" с железом. Например без драйвера для принтера, вы бы не смогли послать ему команду на распечатку текста.
И звук с вашего интерфейса ваш хост принимает также посредством драйвера. Все эти драйверы пишут инженеры фирмы, которая ваш аудио интерфейс выпустила. Различают два "слоя" таких драйверов. Первый "слой" взаимодействует с USB шиной, второй - с вашим хостом. Давайте начнем с простого и поговорим для начала о втором. Подробнее о различиях ASIO и Core Aduio, зачем вообще ASIO нужен на Windows мы поговорим в другом посте.
Задержка декодирования
Откуда берется дополнительная задержка
Сейчас то вы уже наверное догадались, потому что Я решил не путать ваш лишний раз, но на самом деле об этом виновнике редко где встретишь разговоры. А речь конечно о буфере USB шины. USB шина работает на основе миллисекундного таймера, как только таймер отсчитывает определенный интервал, происходит остановка и все что было записано в буфер отправляется на аудио процессинг. Точная настройка этого буфера под характеристики вашего компьютера могла бы дать возможность значительно ускорить процесс работы с аудио, но инженеры умышленно прячут её от вас, а все дело в том что, если пользователь случайно поставит достаточно малое значение этого драйвера, он рискует "уронить" драйвер (при чем как пишут в presonus "crash the driver—a lot.") Как правило большинство (но не все!) производителей значение этого драйвера устанавливают в безопасное для большинства компьютеров значение, которое на деле приводит к лишним 6 мс на входе и выходе. (Также часто можно встретить и 4 мс) Теперь когда мы знаем все этапы цепочки, сложим наши найденные 12 мс с прежде посчитанными 9.7 мс (помните что все значение мы брали в среднем, но результаты на практике сильно не отличаются) и получим 21.7 мс задержки, и вот это уже реальная помеха.
Заключение. Как жить и что делать
Во первых справедливости ради надо заметить, что не все аудио интерфейсы скрывают факты о задержке аудио. Карточки Steinberg UR например в этом плане сразу суммируют значения задержке с двух слоев, и высчитывает различные значения для входного и выходного потока, выдавая вам:
Значение хоть и приблизительное, но по нему действительно можно ориентироваться. При 64 семплах получим задержку
10 мс, что для большинства инструментов не должно стать помехой. И нет, это - не реклама, хотя это явно камень в огород всяким фокусрайтам.
На этом фоне выделяется вокал. Все дело в том что обычно игру на музыкальных инструментах "вживую" сопровождает естественная задержка, а вот вокал мы чувствуем "на себе" сразу. Поэтому многим вокалистам задержка и в 10мс может мешать комфортно исполнять партии.
В большинстве дейвайсов сейчас предусмотрена функция Direct Monitoring, которая пробрасывает сигнал с АЦП сразу к ЦАП. В результате мы все равно имеем около 1мс задержки, но её пока никто "прочувствовать" не смог. Ественно в этом случае мы лишаемся возможности обрабатывать сигнал на хосте.
Вы можете экспериментировать с ещё меньшей задержкой на Windows приобретя например RME Hammerfall, которая позволяет работать под ASIO с буфером в 32 семпла. А на Mac тот же Ur22 будет работать в 32 семпла в силу иной природы устройства их CoreAudio.
Также некоторые карточки, например из линейки presonus AVL позволяют таки изменять размер USB буфера, выбирая между 6, 4 и даже 2 мс. Ещё часть их карточек имеет на борту DSP процессор который позволит проводить direct monitoring с небольшой обработкой для вашего комфорта.
Постскриптум
Как видите зверь не так страшен, если с ним разобраться. И Я надеюсь, что мир цифровой аудиозаписи стал на миг прозрачней и понятней.
Павлин рад тратить свое время на помощь вам, и готов отвечать на ваши вопросы. Свои вопросы задавайте в комментариях.
Павлин не просит ничего взамен, но это не значит что ему не нужна ваша помощь. Если у вас найдется 20 минут свободного времени, вы можете здорово помочь пройдя анкету на тему современной западной поп музыки.
Свои замечания по поводу анкеты вы можете оставлять под предыдущим постом.
Недавно я писал обзор аудиоинтрефейса ESI UGM96, котором вплотную коснулся темы задержки (latency) аудио-сигнала, которая неизбежна при использовании цифровых устройств. Там я «измерял» задержку основываясь на данных, которые выдавал софт: Logic Pro X и Guitar Rig.
Углубляясь в вопрос, стало понятно, что некоторые звуковые карты могут сообщать неправильные значения задержки в DAW и другие программы, поэтому задержку стоит измерять отдельно. Забегая вперед, скажу, что есть определенная методика измерения латенси, есть даже специальный тестовый софт под Win. Прежде чем приступить непосредственно к описанию методики измерения задержки, я бы хотел поподробней остановиться на более общем вопросе: «Что же такое latency? Откуда она берётся?» Есть еще самый главный вопрос: «И какая задержка приемлема?», но, когда я писал эту статью, я понял, что ответ на этот вопрос довольно широк, неоднозначен. В общем, ждите еще одной статьи. Точнее, как минимум 2х. В одной мы поговорим о том, как же-таки измерить задрежку (latency), а в другой поговорим, о том какая задержка приемлема.
Собственно, сегодня речь как раз про латэнси применительно к аудио-интрефейсам.
Скорость распространения звука
Если вы не прогуливали школьные уроки физики, то должны помнить, что скорость распространения звука (т.е. скорость распространения упругих волн) в воздухе составляет 331 м/с. Нетрудно подсчитать, что за одну 1мс звук проходит расстояние равное 0,331 м. Запомним эту цифру, она нам пригодится в будущем для оценки величины латенси.
Нетрудно догадаться, что ВСЕ звуки, которые мы слышим доходят до нашего уха с определенной задержкой, которая зависит от того, насколько далеко находится источник звука от уха слушателя.
Теперь представим себе, источник воспроизводит один и тот же короткий звук с определенным временным промежутком. Так вот, человек будет различать звуки, как раздельные, если между ними прошло от 20 мс до 30 мс. Если один звук отстоит от другого на интервал менее 10 мс, то большинство людей будут думать, что звук вовсе не прерывался. На интервале от 12 мс до 15 мс, человек не способен различить два отдельных звука, но будет это чувствовать, что что-то тут не так. Конечно, конкретные цифры будут индивидуальны для каждого человека, но в среднем – примерно так.
Исходя из вышесказанного, можно сделать вывод, что верхняя граница латенси при работе со звуком на компьютере – это 12 мс. И для справки, 12 мс – это тоже самое, как если бы источник звука находился от вас на расстоянии 3,97 м.
12 мс — цифра довольно спорная, но об этом подбробней будем говорить в следующей статье.
Чем плоха задержка?
Представим довольно распространенную и очевидную ситуацию. Вы играете дома в компьютер через Guitar Rig, например. Так вот, в этом случае мы имеем дело полной задержкой. И вот представьте себе, что задержка у нас больше 12 мс. В этом случае, мы чувствуем или даже слышим, что между тем, как мы дёрнули струну на гитаре и тем, как мы её услышали в наушниках, прошло какое-то время. Это, мягко говоря, некомфортно, особенно при переходе с полностью аналоговой аппаратуры. Впрочем, «порог комфорта» тут сугубо индивидуален – кому-то все хорошо и при 17 мс задержки, а кому-то некомфортно и при 10 мс.
В общем, представьте себе, что вы играете на старом, раздолбанном пианино, к которого есть дефект. Большой дефект, надо сказать, — когда вы нажимаете клавишу, молоточку нужно время в три раза больше обычного, чтобы ударить по струне. Возможно вы всё еще сможете сыграть свои любимые этюды Шопена или соло Professor Longhair, но вот «ощущения» будут уже не те, потому что вам придется компенсировать задержку молоточка.
Или вот наглядный пример с барабаном.
Это была первый, довольно понятный и очевидный вред от задержки. Есть же и менее очевидный, но от этого не менее неприятный побочный эффекты от латенси. О втором вредном (да и вредном ли?) аспекте лэтанси мы поговорим позже.
Задержка (latency) при использовании цифрового интерфейса
Полная задержка (roundtrip latency) – это то время, которое нужно сигналу, на то, что бы пройти путь от аналогового входа аудио интерфейса (на который поступает сигнал с микрофона, гитары итп), через аналого-цифровой преобразователь, в DAW, обратно в интерфейс и в цифро-аналоговый преобразователь, а затем на аналоговый выход интерфейса.
Теперь же давайте поговорим по поподробнее о пути сигнала.
Преобразователи (АЦП/ЦАП)
Первое с чем встречается аналоговый сигнал на входе в наш интерфейс – это аналого-цифровой преобразователь, который, собственно, и делает из аналога набор битов и байтов. Этот довольно сложный процесс в среднем занимает около 0,5 мс. Не забываем, что на другой стороне цепочки стоит цифро-аналоговый преобразователь, который делает из битов и байтов аналоговый сигнал, то есть еще примерно 0,5 мс.
Буферы
Буфер – это специальная область памяти, которая используется для временного хранения (накопления) информации, перед тем, как передать её из одного места в другое. Буферы используются, когда существует разница между скоростью получения данных и скоростью их обработки, или в случае, когда эти скорости переменны. Буфер – это неотъемлемое зло с точки зрения скорости обработки, но, с другой стороны, именно он делает так, что данные обрабатываются точно и без различных артефактов и искажений.
В нашей цепи сигнал буферизируется несколько раз:
Быстрые драйверы и медленные драйверы
Самая большая переменная, влияющая на общую задержку — это производительность (скорость) драйвера.
Драйвер – это специальная компьютерная программа, которая позволяет высокоуровневым приложениям взаимодействовать с конкретными физическими устройствами. Например, любому принтеру нужен драйвер, чтобы взаимодействовать с вашим компьютером. Обычно драйвер взаимодействует с устройством через шину данных или через подсистему связи, к которой подключено устройство. Для каждой операционной системы и конкретных устройств нужны свои драйверы.
Именно поэтому, один и тот же интерфейс может давать разную задержку, в зависимости от операционной системы и производителя материнской платы, точнее контроллера, отвечающего за шину USB.
Одна из основных задач разработчиков аудио-интерфейсов – это обеспечить лучшую производительность драйверов (следовательно, меньшую задержку) при сохранении стабильности всей системы.
Разработчики драйверов для аудио-интерфейсов позволяют нам менять размер буфера. Уменьшая буфер в настройках драйверов, либо в настройках любимой DAW, мы можем уменьшить общую задержку, но увеличить нагрузку на процессор, либо – наоборот, увеличивая буфер, мы увеличим общую задержку, но уменьшим нагрузку на процессор и сделаем систему стабильнее (это может быть актуально при работе на больших и сложных проектах в DAW).
Давайте поговорим об этом поподробнее.
Вернемся к буферу
Буфер был разработан специально для того, чтобы дать процессору необходимое время для обработки информации. Чем большую паузу даст буфер для процессора, тем больше задач он сможет обработать. Но когда буфер слишком большой, то задержка в доставке данных из одного места в другое становится гораздо больше, чем это необходимо для хорошей общей производительности.
Если же сделать размер буфера небольшим, то процессору придется работать «несколько быстрее», чтобы успеть обработать входящий поток данных. Таким образом, возросшая нагрузка на процессор может привести к тому, что все остальные программы, включая вашу DAW могут работать менее стабильно.
Представьте ситуацию. Вы играете на своём любимом виртуальном инструменте и пытаетесь дописать еще одну партию к проекту уже почти законченной композиции. При этом одновременно играют все 42 дорожки, причем на каждой дороже еще понавешано плагинов. Ну и, собственно, вот оно: звук начинает искажаться, вы слышите щелчки и дёргания звука, а то и того хуже — DAW виснет и/или падает, т.к. процессор сильно перегружен. Таким образом, получается, что выставленный вами буфер размером 64 сэмла, который бы в обычных условиях давала приемлемую величину задержки при нормальном быстродействии компьютера, в условиях сложного проекта, слишком сильно нагружает ваш компьютер.
Если увеличить размер буфера, то, возможно, ваша DAW перестанет виснуть и падать, и даже пропадут щелчки и прочие звуковые артефакты. Но не все так просто.
Чем больше вы увеличиваете буфер, скажем до 128 сэмплов, тем отчетливее вы слышите и ощущаете задержку, пытаясь дозаписать свою последнюю партию в проект. Петь или играть на инструменте становится довольно сложно, т.к. у нас тут та же проблема, как и в раздолбанном пианино, про который мы говорили выше. Всё что вы играете, а затем слышите в своих наушниках и мониторах рассыпается по времени. Вот вам и задержка. Получается эдакий эхо-тоннель.
Давайте еще разок вернемся к примеру с пианино. Теперь у нас отличный новый рояль, который не нуждается в каком-либо ремонте. Для простоты давайте примем, что у нас нет механической задержки между тем, как мы ударили по клавише и тем, как молоточек ударил по струне. Скорость звука в воздухе 331 м/с. Это значит, что если мы находимся на расстоянии 1 м от молоточка, то звук до нас дойдет примерно за 3 мс. Так как же получается, что задержка в 3 мс тут нам совершенно некритична, а при выставлении буфера в 2,9 мс (128 сэмплов на 44,1 кГц) в DAW делает фактически невозможным мониторинг гитары, пропущенной через любимый моделирующий плагин?
Расшифровываем латенси
Как мы уже говорили выше, полная задержка — это то время, которое требуется сигналу (например, гитарному соло), чтобы пройти от аналогового выхода аудио-интерфейса, через АЦП, потом в DAW, снова в интерфейс, через ЦАП на аналоговый выход. Мы можем влиять лишь на один параметр в этой цепочке – входную задержку, то есть то время, которое нужно сигналу, чтобы попасть в DAW.
Именно тут в дело вступает драйвер, точнее его производительность. В любом изохронном драйвере (а именно такой используется, как в USB, так и в Fire Wire при передачи потоковой информации, например, аудио сигнала) есть два слоя. Второй слой обеспечивает буфер для Core Audio или ASIO приложений, например, DAW. И это именно тот слой, которым мы можем управлять.
Чтобы всё еще больше запутать, обычно, нам нельзя выставлять размер буфера во временной величине (например, 2,9 мс), вместо этого у нас есть список, привязанный к сэмплам, и мы можем выбирать числа из списка (например, 128 сэмплов). Всё это делает вычисление времени задержки более сложным. А большинство музыкантов скорее запомнят все тексты Rush, нежели то, что 512 сэмплов примерно равно 11-12 мс задержки на частоте дискретизации 44,1 кГц! (Чтобы получить миллисекунды из сэмплов нужно просто разделить число сэмплов на частоту дискретизации. Например, 512 сэмплов / 44100 Гц = 11,6 мс)
Размер буфера, который мы устанавливаем в DAW или настройках драйверов относится сразу и к входному и выходному буферу. То есть, если вы выставили буфер в 128 сэмплов, то и входной и выходной буфер будут равны 128 сэмплов. Таким образом, в самом лучшем случае фактическая задержка будет в два раза больше, выставленного нами буфера. Однако, самый лучший случай – это не всегда то, о чём стоит говорить в контексте передачи аудио данных драйвером.
Например, если в настройках ASIO вы выставили буфер в 128 сэмплов, то только выходная задержка может быть равной 256. В таком случае, может получиться так, что два буфера дадут общую задержку в 384 сэмпла. Что означает, что наши 2,9 мс (128 сэмплов) превратятся в 8,7 мс на частоте 44,1 кГц.
У аналого-цифровых и цифро-аналоговых преобразователей тоже есть своя задержка, т.к. они тоже имеют свой буфер. Эта задержка обычно составляет от 0,2 мс до 1,5 мс в зависимости от качества преобразователя. 1 мс – это не так много и вряд ли повлияет на качество испольнения, но это всё равно вносит вклад в общую задержку. Для нашего примера с буфером в 128 сэмплов, 0,5 мс на каждый преобразователь добавляют к общей задержке 1 мс, то есть из 8,7 мс мы получаем 9,7 мс. Но все равно, 9,7 – это всё еще ниже порога человеческого восприятия и не должно ни на что влиять.
Так откуда берется дополнительная задержка?
Причина кроется в том таинственном первом слое аудио-драйвера, про который обычно никто не говорит. Этот нижний слой (уровень) не имеет отношение ни к аудио-сэмплам, ни к частоте дискретизации. В случае с USB, там есть синхронизатор времени, который называется USB Bus Clock (Синхронизатор шины USB). (В случае с Fire Wire все примерно так же, но тут мы говорим только про USB).
Синхронизатор времени шины USB использует 1-миллисекундные интервалы. По этому интервальному синхронизатору возникает прерывание, инициирующее обработку аудио. Проблема в том, что большинство аудио-производителей, сталкиваясь с этим, не обеспечивают управление над этим низкоуровневым буфером, и пользователи не могут настроить драйвер так точно, как бы им этого хотелось. Объяснение отсутствию доступа к этому уровню довольно простое – пользователь может установить слишком маленький буфер, что может вызвать обрушение драйвера.
Чтобы этого не произошло, большинство производителей фиксирует буфер на величину примерно в 6 мс. В зависимости от аудио-драйвера это даёт нам 6 мс входной задержки и 6 мс выходной задержки. Но тут происходит ровно тоже, о чём мы говорили применительно к ASIO-драйверу, — даже если выставлен одинаковый размер буфера на вход и на выход, выходная задержка может отличаться от входной.
Например, для простоты возьмём, что у латенси в обоих направлениях у нас 6 мс. И вот наша загадка решена – в большинстве аудио-интерфейсов получается по крайней мере 12 мс задержки, которая сидит только в драйверах, и это, не считая тех 9,7 мс, о которых мы говорили выше.
Таким образом получаем, что выставляю задержку в DAW на уровне 2,9 мс, мы получаем общую задержку в 21,7 мс. (Все цифры в этом примере усредненные. Конечно, некоторые разработчики оптимизируют драйверы, чтобы уменьшить эти цифры).
Как же решить проблему латенси?
Многие производители аудио-интерфейсов делают на своих устройствах функцию прямого мониторинга. Это когда сигнал отводится сразу на выход еще до АЦП, да плюс к этому к нему подмешивает выходной сигнал с компьютера. Да, в этом случае задержки никакой нет и мы слышим, минусовку и свой сигнал, и это – очевидный плюс. Минус же тут в том, что сигнал, например, от гитары мы слышим «как есть». Если мы решили записать гитару «в линию», а потом обработать её различными плагинами, то на выходе прямого мониторинга мы будем слышать чистый и тусклый гитарный звук. Никакого вам дж-дж, компрессии или панорамирования. Ну и, само собой, функция прямого мониторинга бесполезна для тех, кто хочет заниматься, используя Amlitube или Guitar Rig, например.
Другие производители встраивают DSP в свои интрефейсы. С помощью этих специальных процессоров можно обрабатывать входной сигнал еще до того, как он попал в шину USB и далее. Управление эффектами обычно производится с панели управления драйверами/микшерно панели, т.е. программно с компьютера. Это уже лучше, но все равно не то. Обычно карты с набортным чипом несколько дороже, да и набор эффектов не поражает воображение (хотя это больше зависит от цены).
Многие производители пошли дальше (например, PreSonus или Line6 с их технологией Tone Direct). Они не заводят сигнал в DAW, а для обработки и мониторинга используют свои приложения, минуя прослойку ASIO. Это кстати, отлично работает в случае Line 6 и использования их отдельного приложения Pod Farm. Ну, а если, плюс к этому еще и поработать над оптимизацией драйвером, то и вовсе всё становится неплохо.
К слову, те же PreSonus, говорят, что на современных компьютерах буфер шины USB можно уменьшить вплоть до 1 мс. Но это в идеале, в среднем – это 2–4 мс.
Ну вот теперь, вроде всё или почти всё понятно с латенси.
Жаль, конечно, что такой подход не работает с любым аудио-интерфейсом и Guitar Rig, например. Но насколько я понимаю, тут нужно чтобы разработчик сам писал и драйвер, и приложение с эффектами и эмуляцией.
Вывод
Ну а в целом, можно сделать вывод, что, во-первых, от задержки все равно никуда не деться, а во-вторых, общая задержка при использовании интерфейса с грамотно оптимизированными драйверами в части USB и ASIO (Core Audio) может дать на круг задержку менее 10 мс, а то и чуть ли не вдвое меньше на частоте дискретизации 44.1 кГц. Что, конечно, не может не радовать, т.к. общая задержка 7-10 мс лично для меня абсолютно незаметна.
PS: В следующей статье мы поговорим о том, какая-таки задержка приемлема? Ответ не так однозначен, как об этом можно подумать. Следите за новостями. =)
Современные компьютеры – идеальные устройства записи. Они могут работать с большим количеством аудио и MIDI-треков, чем нам когда-либо понадобится, а управление и настройка звука с компьютера шагнула далеко вперед. Но важно понимать, что изначальной задачей ПК была вовсе не работа со звуком. Существуют сложности, не свойственные при записи на ленту. Самой большой из таких проблем является задержка: временная разбежка между записываемым звуком и его прослушиванием через наушники или мониторы.
Как образуется задержка звука
Для начала, давайте разберемся, что происходит при записи сигнала на компьютер. Микрофон замеряет изменения давления в воздухе и выдает электрический сигнал с соответствующими изменениями напряжения. Этот сигнал называется аналоговым, потому что изменения электрического потенциала аналогичны колебаниям давления, из которых состоит звук.
Затем устройство, называемое аналого-цифровым преобразователем (АЦП), измеряет или семплирует колеблющееся напряжение с регулярными интервалами – 44,100 раз в секунду (в случае звука с CD - качеством) и сообщает об этих измерениях в виде последовательности чисел.
Секвенция чисел упаковывается в соответствующий формат и отправляется по электрической линии на компьютер. Программное обеспечение на ПК записывает эти данные в память и на диск, обрабатывает их и «отдает» обратно, чтобы их можно было преобразовать обратно в аналоговый сигнал. Такой процесс выполняется с помощью цифро-аналогового преобразователя (ЦАП).
Это довольно сложная последовательность действий, которая зависит от скорости и надежности передачи сигнала. Идеальная ситуация выглядит следующим образом: каждая секвенция, полученная с АЦП отправлена на компьютер, сохранена и отправлена обратно на ЦАП незамедлительно. Но на практике такая схема невозможна. Даже малейшая задержка при отправке хотя бы одного из миллионов семплов в аудиозаписи может привести к дроп-ауту сигнала.
Буферизация сигнала
Чтобы сделать систему более надежной, каждый из семплов не записывается и воспроизводится сразу после его поступления. Вместо этого компьютер ожидает получения нескольких десятков или сотен семплов, прежде чем приступить к их обработке. То же самое происходит на выходе. Этот процесс называется буферизацией и делает систему более устойчивой к неожиданным сбоям. Буфер действует как защитная сеть: даже если поток данных на мгновение прерывается, он способен выводить непрерывную последовательность семплов.
Чем больше размер буфера, тем выше способность системы справляться с непредвиденными ситуациями, и тем меньше времени тратится на обработку. Но есть и недостаток, связанный с большим размером буфера: процесс буферизации занимает больше времени, и в определенный момент, исходящий из компьютера сигнал начинает заметно отставать от записываемого источника звука. В некоторых ситуациях это не проблема, но во многих сценариях это определенно так. Там, где музыканты слушают себя или коллег в процессе записи или исполнения, очень важно, чтобы задержка никогда не становилась слышимой.
Задержка становится слышимой при интервале в несколько миллисекунд.
Важно: существует ряд факторов, влияющих на задержку, но размер буфера (как правило) – самый важный из них и единственный, который может регулировать пользователь.Настройка размера буфера
Размер буфера обычно измеряется в количестве семплов, хотя некоторые интерфейсы предлагают настройку в миллисекундах. Варианты, как правило, увеличиваются в 2 раза: типичная звуковая карта может предлагать настройки 32, 64, 128, 256, 512, 1024 и 2048 семплов.
Вы можете рассчитать теоретическую задержку конкретного варианта размера буфера, удвоив это число (чтобы отразить обработку на входе и выходе) и разделив результат на частоту дискретизации. Так, например, при стандартной частоте дискретизации 44,1 кГц и размере буфера в 32 семпла, задержка составит 1,45 мс.
(32 x 2) / 44100 = 1,45
Такая задержка была бы практически незаметной на практике, но, к сожалению, это невозможно. Во-первых, существуют другие факторы, влияющие на задержку и некоторые из них неизбежны. Во-вторых, некоторые производители звуковых карт «читят», используя дополнительные скрытые буферы, которые находятся вне управления пользователем. В результате заявленные низкие значения задержки не достигаются. Еще один важный аспект в том, что снижение размера буфера вынуждает компьютер выделять больше мощности для поддержки входов/выходов.
Одна из ключевых задач при разработке аудиоинтерфейса заключается в том, чтобы обеспечить возможность использования буферов небольшого размера. Существуют различные варианты, как производители справляются с этой задачей, но сейчас не об этом.
Какая допупстимая длина задержки?
Простого ответа на этот вопрос нет. Звук распространяется со скоростью примерно 0,3 метра в миллисекунду. Поэтому задержка в 10 мс должна ощущаться на расстоянии 3 метров от источника звука, а гитаристы на сцене часто находятся на значительно большем расстоянии от усилителей. Бывают ситуации, когда слышны даже гораздо меньшие задержки. Например, когда музыкант слышит одновременно прямой и записанный звук, любая задержка вызовет гребенчатую фильтрацию между ними. Поэтому, принцип простой: чем меньше – тем лучше.
При использовании MIDI контроллера для игры на виртуальном синтезаторе, звук, который генерируется на компьютере, должен проходить только через выходной буфер. Теоретически это должно означать, что влияние буферизации звука на задержку уменьшается вдвое. Но на практике передача MIDI -данных на компьютер также увеличивает задержку в системе. Объем данных незначителен по сравнению с аудио, но их также необходимо генерировать на MID I инструменте, передавать на компьютер (обычно по USB ) и подавать на виртуальный инструмент.
Все эти шаги занимают небольшое количество времени, но существует вероятность джиттера, при котором задержка не постоянна, а плавает на несколько миллисекунд. Задержка MIDI вряд ли будет заметна, если вы играете на виртуальном синтезаторе партии струнных с пэдов или клавиатуры. Но это может быть проблемой при запускаете семплов ударных. Кроме того, любая система, в которой используется обнаружение высоты тона в MIDI (например, MIDI -гитара) также склонна к заметной задержке на низких нотах, поскольку ей необходимо «видеть» весь цикл сигнала, чтобы обнаружить высоту тона.
Читайте также: