Самодельный Ethernet-транспорт для аудиоинтерфейса. (3 онлайн)
- Автор темы Rst7
- Дата начала
Да.
Указанные выше протоколы используют почему-то (Дима лучше знает почему) UDP, а мы обычный (ну не совсем) TCP/IP.
UDP - протокол без гарантии доставки пакетов и тем, кто его использует, приходится самостоятельно писать часть, отвечающую за перепосылки и подтверждения.
Кроме того у нас свой собственный подход к Клоку.
[DOUBLEPOST=1554280571][/DOUBLEPOST]
Меня и Диму тоже
- так что он будет максимально удобен и наворочан!PS: Я в общем сейчас отдал на разработку Изделие в 4U Туровом Кейсе -
в котором будет шасси для установки ATC материнки с блоком питания и водяным охлаждением, рассчитанным на ГОРЯЧУЮ 9-ую серию Интелов, несколько свичей с PoE питанием для потребителей, хорошая Wi-Fi точка доступа, и!!! 16 аналоговых универсальных входа и 8 выхода наших девайсов.
Т.е. внешне это будет устройство с 16-ю аналоговыми входами и 8-ю выходами, к которому по Ethernet-у можно будет подключить ещё 6 наших девайсов по PoE ( при желании получить в сумме - 64 универсальных входа и 56 выхода) - в девайсах питание тоже по Ethernet-у.
К основному блоку этому легко подключается озвучка любой сложности Барабанной Кухни, к переферийным - ещё 6 музыкантов с инструментом и микрофоном и ушным проводным мониторингом...
Монитора как такового не будет - вместо него любой ноут или планшет по Wi-Fi для управления комплексом - по RDC стандартному Виндовому - работает ПРЕВОСХОДНО!
Последнее редактирование:
Не пишут они ничего. Нет никаких перепосылок в том же AES67. Не пришел - значит не пришел, все.
Дима, если это действительно так - то этот протокол можно использовать (и то с натяжкой) только для трансляции - что собственно и делается.
@Aleksandr Oleynik, в целом при разработке софта (я к примеру по работе связан с контроллерами, которые управляют периферией типа шлагбаумов, светофоров и тд) нет особой разницы тсп юдп, в любом случае придется писать свою часть для проверки целостности, потому как нет точной уверенности никогда, что источник послал все что нужно.
[DOUBLEPOST=1554299397][/DOUBLEPOST]при использовании юдп меньше "накладные расходы" на обертку пакетов - тот же пакет только без айдишки. Если работает одинаково в остальном, зачем грузить оборудование разбором айдишников и добавлять задержку?
[DOUBLEPOST=1554299397][/DOUBLEPOST]при использовании юдп меньше "накладные расходы" на обертку пакетов - тот же пакет только без айдишки. Если работает одинаково в остальном, зачем грузить оборудование разбором айдишников и добавлять задержку?
Если что, то TCP гарантирует доставку. Он именно для этого и разрабатывался. Не нужно после TCP еще что-то проверять (ну кроме полного разрыва соединения, понятное дело).
Я уже тут отвечал, но повторюсь. Если сделать все, что обеспечивает TCP для контроля целостности и перепосылок, то это будет грубо говоря такой же TCP, только самописный. С теми же накладными расходами.
Ну что же это очень радует, так как подготавливать материал для концерта/выступления можно условно сказать на любой зв/карте (ну лично для меня), а вот качественно воспроизводить и обрабатывать в живую какие-то партии инструмент/вокал + плейбэек безо всяких задержек и т.п - вот это будет здорово.
Так, надо внести ясность)) Всё же польза от отключения нулевого ядра нашлась. Даже не смотря на асиогард, при буфере в 32 семпла (это минимальный у РМЕ) с отключенным нулевым ядром рил-тайм пик метр в кубейсе ведёт себя значительно спокойнее и показывает меньшие значения, чем с нулевым ядром. А если запустить latency mon, то с нулевым ядром кубейс вообще перестаёт играть и у асио метра начинается истерика. Отключаешь нулевое ядро и куб успокаивается и спокойно играет.
[DOUBLEPOST=1554392404][/DOUBLEPOST]Но также при отключении нулевого ядра общая загрузка асио метра увеличивается)) Поэтому тут надо хитро лавировать по ситуации))) На минимальном буфере нулевое ядро отключать, а при больших включать.
Я могу пропатченный baios.dll дать, в котором именно просто выключена устрановка Affinity - т.е. поток будет выполняться в любом ядре, а не в нулевом. При этом ядро не отнимается. Правда, у меня в работе только под С9 есть, но могу завтра и для C10 сделать.
Для того чтобы это было "без задержек" нашего девайса мало, вам ещё понадобятся компы соответствующей мощности - ну не менее i9-9900K
Ну и -задержки всё равно будут и будут зависить ещё и от плагинов, вами используемых.
Да это понятно что нужно нормальное железо и оптимизированные плагины, я про то что при неизменном наборе железа и проекта (VST, обработка FX + Playback) и при разных звуковых картах задержка оказывается разной. Что наталкивает на мысль, что от конечного девайса многое зависит, от его начинки, отптимизации драйверов и т.п.
@oigin, я очень боюсь, что опубликованные мной рекорды нашего девайса на топовых Интеловых процессорах многие совершенно не верно растолкуют...
Попробую пояснить чего НЕ СЛЕДУЕТ ждать ни от каких аудио девайсов и от нашего тоже :
- RME по сути достигли теоретического минимума по возможным задержкам в ASIO. И наша задача была добиться тех-же результатов, что на самом деле почти не реально по простой причине - я сравнивал результаты PCI- Ex RME MADI карты и по сути своей внешней Ethernet Аудио карты. У RME, также как и у нашей и у любой другой карты задержка складывается из следующих составляющих (при всех прочих равных условиях) -
- задержка на AD/DA - она зависит только от выбранных чипов и прописанна в документации в общем то это минимум где то 12 сэмплов, что у RME, что у нас.
- задержка на ASIO - она также у всех аудио карт идентичная - это буфер входа и выхода в DAW, за время которой DAW сможет обсчитать всё, что связанно с конкретным проектом - кол-во дорожек, внутренний роутинг, плагины - и все это ни как не связано с аудио девайсом в принципе, задача аудио девайса последовательно передать через свой буфер данные и потом их забрать - и величина этого буфера будет определяться производительностью DAW на конкретном процессоре с конкретным проектом. Повторюсь - эта задержка в общем то от аудио девайса ни как не зависит.
- задержка самого процесса обработки данных в аудио девайсе, мы назвали это Tail Buffer, RME ни как не назвали и не показали её пользователям и не дали её менять. Эта задержка задерживает исключительно выходные данные - на воспроизведении.
- возможно у других производителей аудио девайсов есть и ещё доп задержки нужные их технологии работы, но мы про них ни сего не знаем и они нам не интересны, мы сравниваем свой девайс с лидером.
Вот из-за последних двух составляющих ТАКАЯ РАЗНИЦА в задержке у разных аудио карт!!!!
Ну и теперь собственно - гдеж можно обойти RME в задержках?
Да всё просто -
1. Если проект и комп позволяет - поставить ASIO буфер меньше чем можно выставить у RME. У RME нижний предел буфера 32 сэмпла и дальше он увеличивается в двое - 32, 64, 128, 256 и так далее.
У нас буфер кратен 8- сэмплам 8, 16, 24, 32 и так далее
Вот тут и есть резерв - можем поставить менее 32-х, повторюсь - Если Проект и Мощность компа позволяют, можем поставить в диапазоне от 128 до 256 очень много других значений.
2. Уменьшить Tail буфер. Это очень сложно и редко можно слелать. У RME он не большой, так как это PCI- Ex карта и им данные не нужно выгонять из компа и гонять по сетке. Он у них на 48 kHz = 24 сэмпла жёстко. Я пробовал на нашем девайсе при определённых обстоятельствах ставить меньше - работает, но это только для обработки одного инструмента с набором очень оптимизированных плагинов на мощном железе.
Описал детально, чтоб ни кто не ждал чуда от Аудио Девайса, ни нашего ни чьего бы то ни было.
Попробую пояснить чего НЕ СЛЕДУЕТ ждать ни от каких аудио девайсов и от нашего тоже :
- RME по сути достигли теоретического минимума по возможным задержкам в ASIO. И наша задача была добиться тех-же результатов, что на самом деле почти не реально по простой причине - я сравнивал результаты PCI- Ex RME MADI карты и по сути своей внешней Ethernet Аудио карты. У RME, также как и у нашей и у любой другой карты задержка складывается из следующих составляющих (при всех прочих равных условиях) -
- задержка на AD/DA - она зависит только от выбранных чипов и прописанна в документации в общем то это минимум где то 12 сэмплов, что у RME, что у нас.
- задержка на ASIO - она также у всех аудио карт идентичная - это буфер входа и выхода в DAW, за время которой DAW сможет обсчитать всё, что связанно с конкретным проектом - кол-во дорожек, внутренний роутинг, плагины - и все это ни как не связано с аудио девайсом в принципе, задача аудио девайса последовательно передать через свой буфер данные и потом их забрать - и величина этого буфера будет определяться производительностью DAW на конкретном процессоре с конкретным проектом. Повторюсь - эта задержка в общем то от аудио девайса ни как не зависит.
- задержка самого процесса обработки данных в аудио девайсе, мы назвали это Tail Buffer, RME ни как не назвали и не показали её пользователям и не дали её менять. Эта задержка задерживает исключительно выходные данные - на воспроизведении.
- возможно у других производителей аудио девайсов есть и ещё доп задержки нужные их технологии работы, но мы про них ни сего не знаем и они нам не интересны, мы сравниваем свой девайс с лидером.
Вот из-за последних двух составляющих ТАКАЯ РАЗНИЦА в задержке у разных аудио карт!!!!
Ну и теперь собственно - гдеж можно обойти RME в задержках?
Да всё просто -
1. Если проект и комп позволяет - поставить ASIO буфер меньше чем можно выставить у RME. У RME нижний предел буфера 32 сэмпла и дальше он увеличивается в двое - 32, 64, 128, 256 и так далее.
У нас буфер кратен 8- сэмплам 8, 16, 24, 32 и так далее
Вот тут и есть резерв - можем поставить менее 32-х, повторюсь - Если Проект и Мощность компа позволяют, можем поставить в диапазоне от 128 до 256 очень много других значений.
2. Уменьшить Tail буфер. Это очень сложно и редко можно слелать. У RME он не большой, так как это PCI- Ex карта и им данные не нужно выгонять из компа и гонять по сетке. Он у них на 48 kHz = 24 сэмпла жёстко. Я пробовал на нашем девайсе при определённых обстоятельствах ставить меньше - работает, но это только для обработки одного инструмента с набором очень оптимизированных плагинов на мощном железе.
Описал детально, чтоб ни кто не ждал чуда от Аудио Девайса, ни нашего ни чьего бы то ни было.
Ну допустим что это так, но все же если устройство будет в доступной ценовой категории я готов его попробовать, а так конечно в теории все у всех по разному, а на практике тем более. Будем ждать. Лично мне конечно на данный момент, удобно использовать ноутбук+карта, если бы была возможность поставить стационарный пк, то конечно выбрал бы устройство с PCI подключением. (Увы но пока нет возможности перевозить стационарник и тем более оставлять его на сцене, хотя в теории можно, но пока что на сцене есть 3 разных коллектива и не все приучены относится к оборудованию с уважением - извините за оффтоп). Потому приходится пользоваться ноут+карта - мобильнось (вес) важнее !!!
ЭТО ТАК!
[DOUBLEPOST=1554444588][/DOUBLEPOST]
С ноутами похоже у нас будет затык лет на пять минимум. Опозорился Интел с топовыми мобильными процессорами - не возможно их использовать для длительной работы и тем более в условиях Лайва.
А не топовые - не потянут нормального сэтапа аж ни как. И Аудио Карта тут последняя в очередти ожидающих вас проблем. Ну или планку обработок и функционала прийдётся опустить очень сильно....
Самое мощное из мобильных устройств на сегодня, это Новый Mac Mini с Windows 10 через Буткам -
У него впаянный в плату дэсктопный, не мобильный, современный проц.
При этом использовать его по назначению - с Mac OS и Core Audio - не вариант, так как Core Audio СИЛНО уступает по задержкам ASIO.
[DOUBLEPOST=1554444682][/DOUBLEPOST]
Чё его пробовать? Устройство как устройство
Можно на гитарке играть на 192 kHz-ах с ампсимом на задержке до 1 мс - правда нужен i9-9900K
Последнее редактирование:
Ок, Александр я думаю здесь мы не будем дискутировать по данному вопросу, а то модераторы могут меня "отшлепать" за подобное.
Не отшлёпают....Ок, Александр я думаю здесь мы не будем дискутировать по данному вопросу, а то модераторы могут меня "отшлепать" за подобное.
Я конечно возможно чего-то и не понимаю, но смотря различные ресурсы ( в том числе и всеми любимый видеохостинг) множество профессионально занимающихся музыкантов используют ноут (не стационарный ПК) как правило MacBook + карту iConnectivity iConnect Audio (как пример) к которой подключены два ноута, один из них все дублирует + radial sw8 (8-канальный селектор, устройство предназначено для обеспечения бесперебойного воспроизведения контента во время живых выступлений). Если стационарный ПК (да к тому же на Windows) более предпочтительнее и стабильнее в работе, почему его так редко используют ?
Потому как не знают, и не копают так глубоко. Ну и потому как вес и удобство.
Но все эти конфиги на МакБуках - это 30% мощности от возможной на сегодня.
Но если МакБук нужен для плэйбэка - то ни каких проблем и не будет - только этож тоже бред масса надёжнейших плееров аппаратных есть.
[DOUBLEPOST=1554447553][/DOUBLEPOST]
И как оно обеспечивает бесперебойность? Как определяет, что основной источник пропал?
Последнее редактирование:
Почему ? Потому что с этим справится любой любой бук хоть на винде, хоть на мак ? Или в смысле с этим с правится любое мало мальски мощное устройств о?
Я выше написал - потому как есть аппартные решения, плеера заточенные ТОЛЬКО под это.
Думаю, что всё-же это не просто плэйбэк, а и обработка и какой-то функционал по автоматизации и в композиции и в целом в концертном выступлении.
А вообще - Програмные Лайв Сэтапы находятся в настоящий момент в зародыше.
Их не строят профессионалы, ими занимаются любители музыканты.
Нет, есть уже Аппаратно-Програмные комплексы типпа AVID Venue + сервера от Waves.
Но всё это сильно ограниченно по возможностям, заточенно под конуретного производителя и с цеником космическим за то, что уже давно доступно в совершенно ином ценовом диаппазоне.
Ну я бы не был столь критичным, все же подобные технологии муз/производства в основном зарождаются за рубежом и там же тестируются и активно используются, и используются не только любителями но и профессионалами. Особенно активно используют на западе (и не только) в больших протестанских церквях (Elevation, Hillsong и т.п.)
Я что-то стал запутываться, если с ваших слов за низкую задержку отвечает не только карта, а целом все вместе (карта, софт) и в частности Железная составляющая, тогда в чем преимущество и отличия от других карт (кроме типа подключения) ??? (я почему то думал что именно с вашим девайсом будет меньше задержка и стабильность)
А я не категоричен, я просто общаюсь с ними со многими и знаю КАК это всё ими выбиралось и почему.
А тут либо я вас запутаю ещё больше, либо прийдётся организовать беседу часа на два с примерами.Я что-то стал запутываться, если с ваших слов за низкую задержку отвечает не только карта, а целом все вместе (карта, софт) и в частности Железная составляющая, тогда в чем преимущество и отличия от других карт (кроме типа подключения) ??? (я почему то думал что именно с вашим девайсом будет меньше задержка и стабильность)
Если хотите - можем.
Но по простому - Аудио Девайс нужен ХОРОШИЙ (вот тут конечно критерии у всех разные, например - красный
- не смотря на то, что по всем тестам Фокусрайты оутсайдеры - а по продажам они лидеры ), с Хорошими драйверами и без дополнительных Буферов Задержки, которые нужны для устранения собственных косяков и криворуких програмистов (и кто в состjянии эти параметры правильно оценить??????, ну разве что глючность драйверов оценить могут - и тут конечно RME, ну из тех что продаются).И поскольку время не стоит на месте, лучше не иметь в Девайсе органичений не нижних величин ни по градации их в буфере, чтоб выбрать оптимальный буфер, а не тот, что позволил производитель.
Вот НАШ Девайс всем этим требованиям и отвечает (правда пока блин не красный
). Кроме того он функциональнее большинства на рынке.НО! Он не спасёт вашу задержку на слабом ноуте или убитой играми и лазанием по инету операционке АЖ НИ КАК!
Последнее редактирование: