PCI (PCI-X) sound interface latency vs. fireware latency

[trance_lucent]

Возможно, спрошу глупость.

Правда ли, что у файрвайр-звуковых интерфейсов имеется дополнительная задержка (связанная с передачей по самому файрвайр)? Нет, я понимаю, что задержка имеется везде по всему звуковому тракту, но тут, вроде как, речь идёт о нескольких миллисекундах? В частности, попадались упоминания случаев, когда при выставленном буфере в 2.9 миллисекунд общая задержка до выхода составляла ~6 мсек, а также рекомендации "хочется низкую задержку - берите pce-x-интерфейс".

Дополнение. Кроме того, недавно в каком-то из русских обзоров устройств читал (про файрбокс, кажется), что из-за того, что он файрвайр-интерфейс, он на 50% (!) нагружает сильнее процессор, по сравнению с pci. Выглядит бредово, но мало ли?

 

[q_h]

<div class='quotetop'>Цитата</div>

но тут, вроде как, речь идёт о нескольких миллисекундах?[/b]

http://www.centrance.com/forum/viewtopic.php?t=68

 

[trance_lucent]

q_h,
Спасибо. Это ж тихий ужас!
Только я так и не понял, от чего получаются разные результаты задержки - из-за разных fireware-контроллеров, или всё же они зависят только от аудиоинтерфейса (установки буфера я не рассматриваю).

И, всё-таки, остаётся вопрос насчёт загрузки процессора при использовании fireware по сравнению с pci(x).

 

[mxc]

У меня следующие цифры были в Nuendo:
Presonus Firestudio (FW) - ~3 ms
Steinberg VSL2020 (PCI) - 0.5 ms

 

[trance_lucent]

Andrey ivanov,
Спасибо.

Да, но, тем не менее, в интернете я нашёл множество отзывов о round trip latency > 10 мс (при небольших буферах), и жалобы, что задержка ощутима при живой игре.

Т. к. я живу не в Москве, мне не реально найти вариант с манибеком, поэтому рисковать не хочется. Может, есть какие-то известные решения для макинтошей с низким round trip latency?

Дополнительные требования к интерфейсу я привёл в http://forum.rmmedia.ru/index.php?showtopi...mp;#entry510179 , хотя, как оказалось, сама тема была создана ошибочно (перепутал pci-x с pci-e).

Что ещё интересно, на
http://www.gearslutz.com/board/music-compu...ire-vs-pci.html
сказали, что на маках fireware работает с большей задержкой, чем на pc...

ЗЫ. К тому же, всегда неприятно установить буфер на минимум, жертвуя ресурсами процессора, и получить при этом задержку, как на простой pci-карте с установленным средним объёмом буфера (и мЕньшим потреблением процессора). Получается, что, действительно, fireware В ЭТОМ смысле потребляет больше ресурсов процессора (при одной и той же задержке).

 

[trance_lucent]

mxc,
<div class='quotetop'>Цитата</div>

У меня следующие цифры были в Nuendo:
Presonus Firestudio (FW) - ~3 ms
Steinberg VSL2020 (PCI) - 0.5 ms[/b]

Это буфер или реальная задержка?

Нашёл здесь
http://forum.nuendo.com/phpbb2/viewtopic.p...#g7zround-trip0
вот что:

<div class='quotetop'>Цитата</div>

VSL2020 same test config 3.11

So the math seems to be ok (at least for the VSL2020). Let's see... (all figures are aproximate and @ 44.1 kHz as messured by Mysteryman)

32 samples for the input buffer + 32 samples for the output buffer = 64 samples round-trip = 1.45 ms
There are 1.66 ms left (3.11 ms - 1.45 ms) / 2 (for both converter stages) = 0.83 ms = 36 samples

36 samples is completely normal for a converter.[/b]

Просто удивляюсь числу "0.5 мсек" на фоне того, что у Symphony, например, заявляется 1.5 мсек полная задержка, и это считается круто.

 

[mxc]

<div class='quotetop'>Цитата(trance_lucent @ Oct 19 2007, 05:09 PM) [snapback]510426[/snapback]</div>

mxc,
Это буфер или реальная задержка?
[/b]

Это цифры, которые Nuendo пишет в закладке ASIO bay.
Померять и сказать точнее пока не могу, VSL2020 лежит в шкафу, пользую ноутбук с Firestudio.
Проблема только в выборе конкретной модели интерфейса. Остальное очевидно - PCI в любой своей модификации быстрее и стабильнее FW.
Если б было иначе, я бы не стал заморачиваться с покупкой VSL2020 в Германии.

 

[goonik]

хмм.. я бы посмотрел на задержки РМЕ

 

[trance_lucent]

mxc,
А это при какой частоте оцифровки?

Кстати, вот что я нашёл на http://forum.cakewalk.com/tm.asp?m=1034458:

<div class='quotetop'>Цитата</div>

The FF400/800 use a 64 sample 'safety buffer' on the playback side... and the PCI/e RME audio interfaces use a 32 sample safety buffer on the playback side.

So... at a 64 sample buffer size @ 44.1k, that translates to a round-trip latency of 6.1ms.
The best round-trip latency currently available (using the above settings) is ~5.5ms. So that's not bad...

The safety buffers on M-Audio, Presonus, and Focusrite FW devices are significantly larger... and literally double the round-trip latency. ie: A stock Presonus or M-Audio FW interface with a 64 sample buffer size @ 44.1k yields a round-trip latency of ~11ms. And that's as low as they go... (too high for play thru soft EFX in realtime).
[/b]

Видимо, действительно нужно ждать HDSPe 9632... Жалко, конечно, у мобильных решений есть свои преимущества, и не только в мобильности, а и в "стэндалонности".

 

[mxc]

<div class='quotetop'>Цитата(trance_lucent @ Oct 22 2007, 10:29 AM) [snapback]511879[/snapback]</div>

mxc,
А это при какой частоте оцифровки?
[/b]

44 kHz
Странно, что вы так... придирчиво считаете милисекунды задержки.
Пробовал как-то "вживую" обрабатывать сигнал от микрофона через микшер Nuendo через Firepod (он у меня тоже есть и имеет задержку, большую чем Firestudio) на 44 к. Ощутимая на слух задержка чувствуется только на "тяжелых" плагинах.
"Вхолостую" (при отсутствии плагинов) сложение прямого и возвращенного из VST-микшера сигнала на слух не "двоит" и не дает фазовых сдвигов. Все это на процессоре Centrino.
Надеюсь, помог.

 

[trance_lucent]

mxc,
Спасибо.
Попробую немного объяснить.

1. Я не совсем дурак. Я знаю, задержка есть везде. Даже в воздухе - сидим мы на расстоянии метра от мониторов - это уже около 3 миллисекунд на то, чтобы волне до нас дойти.
В этом и дело - задержка здесь, задержка там. В сумме и набегают порой десятки миллисекунд (в запущенных случаях). Если хочется минимизировать задержку, то нужно искать самые слабые места, где задержка максимальна, и которые при этом легко поддаются корректировке. Аудиоинтерфейс - это именно такое место.

2. Я не совсем уж маньяк. Я могу с относительным комфортом играть при задержке 30 мсек. При 20 и ниже я даже уже привыкаю и перестаю замечать эту задержку, особенно если то, что я играю - спокойная музыка. При 10 и ниже я уже не слышу задержку в любых случаях, хотя в интернете полно людей, которые считают такую задержку недопустимо большой.

Но есть ещё одна фишка. Я не очень люблю экстремальные настройки чего либо - когда система работает на пределе. При буфере в 32/64 сэмпла даже в лоджике поднимается потребление ресурсов. Виртуальные студии - это пакетные передачи/обработки данных, поэтому повышение потребления - это закон. В кубе же, как выяснилось, зависимость потребления от задежрки вообще крайне сильна, хорошо, что я не кубист. Таким образом, как я говорил, очень неприятно работать с буфером в 32/64 сэмпла, ожидая дропауты и мирясь с повышенной жручестью ресурсов и получая при этом ту же задержку, которую можно получить на PCI(e) с буфером 256 сэмплов - при этом имея гарантию отсутствия дропаутов и умеренное потребление ресурсов.

Да, Fireware может обеспечить идеальную для меня задержку в 10 мсек или меньше, но вот до сих пор не могу решить, стоят ли этого неудобства, вызванные использованием буфера 32/64 вместо 128/256.

Возможно, я не прав. В конце концов, судя по отзывам, лоджик работает с малыми буферами просто идеально. Да я и сам убедился в этом по встроенной звуковухе.

Однако те Fireware-решения, которые способны обеспечить RTL < 10 мсек, как я понял, начинаются от Fireface400, который стоит дороже HDSPe 9632 (наверное).

сейчас вот подумал, что мне, наверное, можно не ориентироваться на RTL - ведь для меня критична только задержка в одну сторону - на выход. Грубо считать - она в два раза меньше ведь?

ЗЫ. Я тут не рассматривал случаи плагинов, требующих специальные буферы (например, использующих FFT). Там уже говорить о задержках не имеет смысла.

 

[Aleksandr Oleynik]

Тема очень интересная. У меня тоже каша некоторая в голове имеется, особенно если говорить о ПОЛНОЙ задержки звукового тракта в котором по мимо задержки на самом железе есть, как это я понимаю, задержки интерфейса передачи данных, того-же ASIO и/или Core Audio.
Я не очень доверяю той цифре которую пишет Cubase (Nuendo) в ASIO закладке, и если говорить о сквозном тракте (вход - обработка - выход) то эта показываемая Стэйнбергом задержка наверное должна быть умножена на 2?
Использовать в Cubase буфер 64 просто не реально даже на 4-х процевых Маках, хотябы по той причине, что проблеммы с дропами, искажениями и пр. на слух не так просто сразу заметить, а Индикации таких проблем в Сиквенсоре почему-то нет, хотя я бы очень этого хотел.

Не думаю, что интерфейсы таких FW железок как RME FF800 (FF400) дают задержку больше чем их PCIe собратья.

 

[trance_lucent]

Aleksandr_Oleynik,
<div class='quotetop'>Цитата</div>

Не думаю, что интерфейсы таких FW железок как RME FF800 (FF400) дают задержку больше чем их PCIe собратья.[/b]

На Apogee Symphony получали RTL = 2мсек (@44.1 кГц. На сайте заявлено 1.5 - но это для 96 кГц). На Fireface возможно только 5.5 мсек (я писал выше).

Да, и, кстати. Если уж гнаться за низкими задержками, то, похоже, куб тут не товарищ.
http://www.cubase.net/phpbb2/viewtopic.php...828ec0350ed5b93
По тамошним тестам, на низких установках буферов лоджик обгоняет куб В РАЗЫ. Без всяких дропаутов. Хотя тесты, конечно, проведены весьма сомнительно.