Самодельный Ethernet-транспорт для аудиоинтерфейса.

  • Автор темы Автор темы Rst7
  • Дата начала Дата начала
есть вот такой разъём, недорогой, надёжный

Все. Необходимое и достаточное условие. И да, в конструкции нет клепанного соединения между штырем и лепестком для припайки провода - это самое узкое место в этих разъемах. Проблемы в нем начинаются при самой первой припайке провода из-за теплового расширения лепестка.

Добавлю, что он небольшой (размером с обычный залитый разъем на патчкорде):

photo_2019-03-17_17-38-39.jpg

Еще раз, вот очень прошу, давайте закончим с разъемами.
 
[HIDE-POSTS=15000]иногда начинаю думать, что наличие короткой обратной связи с пользователями - как минимум, не полезно. ;)[/HIDE-POSTS]
 
Чтобы увидеть содержимое у вас должно быть 15000 или более сообщений на форуме.**

-- Крууууто.... ;)
Ну, ладно - лет через 5-6 прочту!
Если доживу, конечно.... :(

>ставить на питание четырёхпиновый XLR

-- Лучше бы таки мини-XLR.
Дабы от шаловливых ручек уберечься.
 
[HIDE-POSTS=2500]иногда начинаю думать, что наличие короткой обратной связи с пользователями - как минимум, не полезно. ;)[/HIDE-POSTS]
[HIDE-POSTS=2500]Та мы же взрослые дядьки с Димой, с опытом и производственным и эксплуатации.
Мы и свои предпочтения засовываем в дальний угол шкафа и анализируем по многу раз то, что собираемся сделать.
Мнение пользователей о функционале, внешнем виде, эксплутационных характеристиках полезно знать. Но этож все люди, с тем или иным опытом, со своими предпочтениями и тараканами.
Ну вот и задачка - услышать тех, кого обязательно нужно было услышать, что-то, что тупо пропустили.
PS: Кстати, в мире создания новых устройств и технологий есть два подхода, их в общем называли всегда - Японский и Американский.
Американцы делают кучу опросов, собирают мнения, а потом делают что-то, что удовлетворит потребительский спрос большинства.
Японцы на столько дальше смотрят (смотрели...) в будующее, чем пользователи, что ни у кого ни чего, кроме специалистов задействованных в процессе, не спрашивают - создают продукт с НОВЫМИ потребительскими свойствами и потом навязывают его пользователю.
Но так было раньше, теперь, как я вижу, всё перемешалось....[/HIDE-POSTS]
 
Последнее редактирование:
  • Like
Реакции: Scarlatino и mexap
я правильно понимаю, что можно набрать кучу таких девайсов, поставить в тонзале и туде гигабитный свич, а в компе у меня будет милиард каналов приходящих/исходящих?
 
я правильно понимаю, что можно набрать кучу таких девайсов, поставить в тонзале и туде гигабитный свич, а в компе у меня будет милиард каналов приходящих/исходящих?
На этот вопрос уже много раз отвечали - ДА!, в этом и есть основной смысл данной технологии.
 
  • Like
Реакции: Urus
Adi pro 2 которая стоит 138 тысяч деревянных рубликов сейчас ;)
и в которой нет нихрена кроме цап ацп ) даже тоталмикса нет
 
Ну в ADI-2 PRO ЦАП заметно лучше стоит. Так что совсем прямое сравнение некорректно.
Так спрашивали только о ЦАП-е, так что - очень даже корректно я сравнил :)
[DOUBLEPOST=1552920004][/DOUBLEPOST]
Так и у нас нет :-D
Так у нас будет на много лучше ............ :) .............. наверное :(
 
а нет мыслей сделать конвертер ADAT, EBU, SPDI/F в одном корпусе для тех, кто имеет 8200 уже н-р?
На этот вопрос тоже уже отвечали где-то тут.
Мыслей много, рук и голов мало... Всё очень и очень последовательно.... Пока можно будет подарить детской муз школе 8200 и купить наш девайс полноценный, тем более он будет на голову качественее, чем ADA8200 и не на много дороже. :)
 
Последнее редактирование:
полноценный это с 8ю мик. преампами и 8ю аналог. выходами?
Да. Не скоро видимо, но всё равно быстрее чем мы сделаем бриджи в другие цифровые стандарты.
Кстати, преампов, в обычном понимании этого термина, у нас нет - у нас универсальный вход с автоматическим (дискретным) изменением чувствительности в аналоговой его части, конечно с возможностью подать 48 v.
 
Последнее редактирование:
  • Like
Реакции: mxc и Scarlatino
Ещё немного информации, как будто мы об этом ещё не писали.
Всё управление нашими девайсами организованно по OSC протоколу, который на сегодня является уже практически стандартом управления в мире мультимедиа и поддерживается и многими DAW и кучей разных конструкторов для пользовательских Ремоутов (Touch OSC, Lemur). Протокол полностью открытый и бесплатный.
Что это обозначает?
А то, что при желании можно включить управление любыми параметрами наших девайсов в свой кастомный ремоут.
Мы безусловно опубликуем весть перечень используемых команд и фидбэков.

Для примера могу опубликовать скриншоты созданного уже для iOS ремоута под наши девайсы (под Android тоже уже есть) -

E31D1408-1A11-40C9-99E4-D2FB9982935C.png
2473591E-84B5-4723-B34E-E558B86D9C4E.png
9C047335-2D02-465C-A49F-E39FC9884DAD.png
4948EDAC-E139-48F4-BA18-51C66E9833B1.png
7C9882D3-12E3-4D76-8943-9030DA3D84EF.png
6D78DD7B-5849-4BEF-9177-CA87B67304D7.png
56FD89DF-6D79-482A-970C-04B869B1FA6D.png

В общем на скриншотах ответ на вопросы - а гдеж ручка громкости или уровня входа или переключение чувствительности канала или индикация уровня. На девайсах пока не планируется устанавливать не единого органа управления или контроля (есть только один мультифункциональный RGB светодиод) - всё управление по цифре, по OSC протоколу (как писал выше) по той же сети, по которой гуляет и звуковой поток.
 
Последнее редактирование:
Это лучше Дима расскажет...
Ну и патч этот интегрирован в наш ASIO драйвер, иначе ни как - или хакать сами DAW или писать разработчикам.
В двух словах я уже где то писал - Рипер «засыпает» периодически, а «будить» его не кому, если процессы менее 1 мс, так как побудка организована штатными средствами виндового планировщика - а у него минимальная еденица измерения - 1 мс.
С Кубом - нужно отключать от процессинга нулевое ядро, так как Куб в нём считает все предварительные данные, без которых ни чего не начнётся!!!
 
Последнее редактирование:
А что даёт это в практическом смысле?

Уменьшается загрузка ASIO. В двух словах там ситуация такая:

Есть основной поток, который находится в Baios.dll. Этот основной поток выполняет роль планировщика для остальных - запускает их, готовит задания, и так далее (да, некоторая часть собственно обработки тоже выполняется в этом потоке). Почему-то уважаемые решили, что этот поток надо принудительно запускать только на нулевом ядре. В результате есть вот такая картина:

c10_core0.png


От вертикальной серой черты до второй серой черты - это полностью обработка одного буфера. Третья вертикальная серая черта - это начало обработки следующего буфера.

Внизу - распределение по ядрам. Именно в ядре 0 выполняется поток 592 (подсвечен темносиним вверху) - это тот самый основной поток. Только время от времени он прерывается всякими системными делами - DPC и прочим, которые по умолчанию выполняются в потоке 0. В результате у него не получается вовремя готовить задания для других потоков - это черные дырки в остальных ядрах (нижний график). Т.е. другие потоки заканчивают заметно раньше ожидаемого времени, и просто простаивают, пока из основного потока им не упадет новая задача.

Если забрать у Кубейса нулевое ядро, то основной поток начинает работать на произвольных ядрах. Даже если его вытесняет кто-то, то его работа продолжится на другом ядре. Результат:

c10_core0disable.png


На этом примере основной поток работает сначала на ядре 2, потом 6, потом 4.

Тот же масштаб, но количество дырок резко уменьшилось. Соответственно, времени обработка того же проекта занимает меньше (сравните прошедшее время между двумя серыми чертами на первом и втором графике).

На втором примере хорошо видно, что нулевое ядро довольно сильно занято всякими процессами системными.

Самое интересное, что в audioengine.properties есть параметры, которые позволяют не привязывать к ядрам потоки обработки данных, но именно отцепить от нулевого ядра основной поток - невозможно. Только путем выставления Process Affinity Mask.
 

Сейчас просматривают