Возможно и так, просто на Лайве любая доп коробочка со шнурами - это огромный минус.На самом деле их не надо делать в виде кучи вариантов.
Но для коммерческого решения - коробочка - вход adat - выход Ethernet - это КРУТО!
Возможно и так, просто на Лайве любая доп коробочка со шнурами - это огромный минус.На самом деле их не надо делать в виде кучи вариантов.
Ну как бы любой переход в юзерспейс так устроен. Но тут есть нюансы. TCP-стеки нынче в ОС компов очень оптимизированы под большую загрузку. Есть даже специальные средства минимизации времени перехода в юзерспейс из стека и обратно. Например, в винде это Registered IO. Я пробовал, но для конкретно этих целей - из пушки по воробьям, различия между банальным winsock и RIO незаметны, вот если бы там были гигабитные траффики, тогда да.не смущает
полагаю что азио драйвер "будит" DAW по получении пакета - и время реакции от получения пакета (в вашем случае по ethernet) до пробуждения вашего процесса (и как следствие пробужденяи DAW) - будет вычтено из того времени что отведено на обработку пакета
Т.е. на самом деле 3 ms это физический минимум?Просто туда-сюда пробросить 64 семпла (для круглого счета я оперирую частотой дискретизации 48кГц) можно за 2.7мс. Но есть нюанс. Необходим хвостовой буфер, который будет выполнять две функции - устранять джиттер самой обработки в DAW (она довольно сильно по времени разнится) плюс запас на перепосылку пакета в случае его утери. Реально запас на перепосылку нужен в моем варианте на 24 семпла, т.е. на 0.5мс. Так что 2 не получится никак.
Ну зато там кое-какие технические трудности снимаются. В частности, сам по себе принцип работы моего девайса удобен для получения данных, скажем, с 8 синхронизированных вместе I2S-интерфейсов, но не очень удобен для получения данных с двух независимых (хоть бы и синхронизированных мастерклоком) потоков ADAT. Ну не будут они с точностью до битовой синхронизации синхронны. А вот объединить эти потоки потом в компе - раз плюнуть.Возможно и так, просто на Лайве любая доп коробочка со шнурами - это огромный минус.
Ну им же не нужно время запасать на перепосылку пакета. А если АЦП и ЦАП'ы там реально в режиме с минимальными длинами фильтров, то все очень похоже. А этой известной тестовой софтиной проверялись эти цифры?Кстати, у RME MADI при 48 kHz и 64 spl - 1,4 ms вход и 1,7 ms выход - т.е. реально 3,1 ms!
я не за ради спора - но пропускная способность и латентность это две большие разницы всежНу как бы любой переход в юзерспейс так устроен. Но тут есть нюансы. TCP-стеки нынче в ОС компов очень оптимизированы под большую загрузку. Есть даже специальные средства минимизации времени перехода в юзерспейс из стека и обратно. Например, в винде это Registered IO. Я пробовал, но для конкретно этих целей - из пушки по воробьям, различия между банальным winsock и RIO незаметны, вот если бы там были гигабитные траффики, тогда да.
Это тоже самое в конкретно данном контексте. Почитайте про RIO, есть в русскоязычном сегменте пара хороших статей, как там все это устроено и в чем профиты.я не за ради спора - но пропускная способность и латентность это две большие разницы всеж
Вот я бы с удовольствием предоставил возможность проведения такого теста кому-то другомусколько эффектов\дорожек например "вывозит" DAW на вашем решении и на каком-нибудь "общепринятом"
Ну самый простой и оптимальный вариант для моего девайса (назовем его так) - MCLK - хорошим генератором, LRCK - банальным делителем из MCLK, а все конверторы - в slave-режиме, BICK я генерирую сам.4 канала ввода и 4 канала вывода данных, физически 2 провода din и 2 провода dout не считая синхры конечно, mclk
bclk rlck общие, причем синхру можно сформировать непосредственно в конвертерах ( так лучше)
Естественно.А этой известной тестовой софтиной проверялись эти цифры?
Я готов. И для этого всё есть. Можно и совместно - приглашаю в свою студию в КиевеВот я бы с удовольствием предоставил возможность проведения такого теста кому-то другому .
-дурак не дурак а все новые интерфейсы до 192кгц, да и предыдущие были до 96к , не считаяБеренджер не дурак
В контексте ЭТОЙ темы.В контексте этой темы или вообще?
Ну почему же так категорично. Драйвер от этого Tascam'а (до того, как я его не замучал ) тоже рапортовал в DAW реальные цифры.RME чуть ли не единственная компания, у которой то, что показывает DAW = реальным цифрам.
96 точно получится, особенно если ограничиться 8ю каналов на девайс, а не 16, как сейчас. В рамках обсуждаемой коробочки с ADAT-ом вообще не потребует лишних телодвижений (имеется в виду S/MUX). Получится ли 192 - не знаю, надо проверять. В том виде, в каком сейчас - наверное не получится, не хватит производительности. Есть там некоторые нюансы реализации, но есть и резервы по оптимизации.Но тем ни менее, про 96 и 192 по Ethernet в комп я бы тоже послушал.
А напомните пожалуйста (я где-то в какой-то теме встречал цифры, вроде Вы их озвучивали, но что-то подзабыл), вот у этого вашего моднейшего сетапа для лайвов сколько загрузка ASIO в процентах (ну порядок цифр)? И правильно ли я помню/понимаю, что у вас там буфер 64 семлпа?Но нужно проверить на РЕАЛЬНЫХ сложных проектах и на стабильность и на производительность.
Ну вот... оказывается не важно куда, а важно что и то, что летит.-ну совсем она не к марсу летит , а скажем так в сторону от земли ,
Боинг тоже банкрот, а все мы летаим на произведенных ими самолётах, Гибсон вон банкрот - а у каждого уважающего себя гитариста Гибсон есть.и при всем уважении к тов.Маску по
слухам он фактически банкрот
По моим наблюдениям число очень похоже, ну может быть я оценил бы его чуть выше, ближе к 70%. Само по себе время обработки одного буфера нестабильно (кэши, гипертрейдинг, прочее, прочее) и да, мои замеры примерно о том же говорят, что по достижении где-то этого порога начинаются единичные перелеты за время, отведенное на обработку одного буфера. Дальше вопрос только в том, насколько эти перелеты часты и хватает ли хвостового буфера их компенсировать.Загрузка должна быть не выше 60% иначе точно пойдут цифровые искажения.
Если она выше 60% приходится уходить на следующую градацию буфера.
На сегодня у меня в проекте с 16ю входами и 16ю выходами, с около 200-ми треками обработки с FX-ами ——- 64 spl и до 56% загрузки ASIO по индикатору RT CPU Рипера.
Самое смешное, что заветное число ~60% практически постоянно независимо от производительности компа.Но это всё не только от аудио интерфейса зависит - это у меня на 10-и ядерном i7 разогнанном до 4,2 GHz.
За всех не скажу, могу только ответственно заявить, что весь метал, который пишется в Украине и издается на европейских/штатовских лейблах за гонорар (это важное уточнение, как бы оно странно не звучало), точно пишется в 44 (иногда в 48).практически у всех кого знаю 88.2к-96к
За i3 ничего не могу сказать, но после последнего самовольного обновления 10-й винды (которое я изо всех сил старался предотвратить) ноут с мобильным i5 неожиданно стал спокойно не напрягаясь тянуть BIAS + барабанный трэк в супе на минимальной задержке (16spl на фокусрайте 2-го поколения), RT показывает 29-30%. Я на радостях обновился на компе, но там чуда не произошло, на той же винде с той-же картой и дровами на 16 сэмплах Xeon-ы подхрипывают))), хоть с HT хоть без, хотя RT там вообще на грани статистической погрешности.как раз на малых задержках чудовищно зависимо .
какой нить core i3 бы просто сразу захрипел на в половину меньшей загрузке процессора...
Я думаю, что пороговая загрузка ASIO в 60% не зависит (и не должна) от мощности процессора.@Zerocool, ну вот давайте сравнивать. У уважаемого Александра 10тигоршковый процессор, разогнаный до 4.2ГГц. У меня - 4хгоршковый, на частоте 2.9, тоже i7. А пороговые цифры одинаковые. И да, размеры буферов малы - 64 или 48 семплов.
Вот лучше звук при повышении частоты или нет - точно ни чего не значит в контексте того опроса, ПРОСТОГО, который я устроил.-да я уже голоснул, но этот опрос мало что значит т.к давно известно чем выше fs тем выше полоса и лучше звук , правда
тут есть одна тонкость связанная конкретно с ацп , то что стоит в подавляющем большинстве интерфейсов на fsx4
работают хуже чем fs и fsx2 ( растет с.ш и к.г)
А вот опрос говорит об обратном. И будет сей интерфейс продаваем или нет - зависит ТОЛЬКО от двух вещей - его надежности и цены.-лично мое мнение кому какая нужна fs такую и ставить , я просто говорил конкретно про продаваемость, 44.1-48 в виде интерфейса просто
непродаваемые хоть там супер пупер всего наставь
Ну ок. Есть проц с 4.2, а есть с 2.9. А относительные цифры - одинаковые.Александр за меня ответил , и да , большего всего именно это зависит от тактовой частоты даже , а не от количества ядер )
Ну вот и я про то же толкую. С ключевым словом "относительная нагрузка". Причем именно ASIO, а не Cpu Load в диспетчере задач.относительная нагрузка на ASIO после которой кирдык - одинаковая