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

  • Автор темы Автор темы Rst7
  • Дата начала Дата начала
ну, без шуток - я не представляю себе как бы я двигал левый мик относительно правого (в случае оверхэдов) после записи.
Просто подвинуть дорожку с левым микрофоном на несколько туда/сюда нельзя чтоли?
 
@Radiator, Нельзя. Фотку я запостил где ваще никак нельзя. Мне кажется топикстартер меня проклянет если я этот оффтоп еще и поддерживать стану, сорри.
Мне был интересен механизм синхронизации двух интерфейсов по эзернету с точностю до сэмпла. Не хотел совсем чтоб это вылилось в это вот все. Глядишь щас ругань пойдет =\
 
По итогу - что в AES, что в SPDIF - нет фреймовой синхронизации.
-это да у разных устройств будет разнофаз на высоких частотах , для этого там синхра по wc предусмотрена,
я имел ввиду конечно одно стерео устройство , многоканал и несколько устройств это другая песня
-можно еще ввести обратную синхронизацию по тому же aes spdif правда не уверен что при этом разнофаза
не будет
@digilab2, а как же цезий?
-такая стабильность просто не имеет смысла в нашем случае , к тому же у них фазовый шум большой т.к приведение к нужным
частотам это синтезатор , осхо значительно проще и фазовый шум очень хороший( если изготовитель правильный)
 
Последнее редактирование:
Нельзя. Фотку я запостил где ваще никак нельзя. Мне кажется топикстартер меня проклянет если я этот оффтоп еще и поддерживать стану, сорри.

В общем-то это достаточно узкий момент, который вполне можно обсудить.

а) Двигать можно всегда и везде. Я всегда треки оверхэдов и румов поканально двигаю после записи барабанов. По многим причинам. Основная - невозможно точно установить микрофоны на одинаковой дистанции да еще и до неточечного источника звука. Во-вторых, просто удары по малому барабану вполне могут привести к тому, что на сантиметр он уедет в сторону. А это, на секундочку, больше одного семпла на 48к. Это не говоря уже о том, что сам барабанщик может двинуть малый. В-третьих есть всегда присутствующие эффекты ветра. А точнее - тепловых градиентов. Хотя бы только потому, что барабанщик даже не стуча в барабаны сотню ватт тепла генерирует. Скорость звука меняется, и меняется она до каждого микрофона по своему (потому что нифига там не равномерное поле температур). Типичная ситуация - прописали трек целиком, и надо вписать пару сбивок технически сложных, которые не удалось закатать с первого дубля. Долго парились, и наконец-то прописали. Потом при редактировании оказывается, что смещение оверов/румов на самом первом дубле сильно отличается от последнего. Потому что изменилась температура, пока барабанщик в матюках два десятка дублей сбивки прописывал. Кому там какая разница, что на пару микросекунд в одном девайсе запаздывает точка семплирования, например?

б) Про фотографию. Так почему же "никак нельзя двигать"? И второе - ну вот Вы поставили микрофоны, послушали звук в контрольной комнате через уже АЦП, DAW и прочее, приняли решение - годится. И пишете. С чего это вдруг задержки сильно изменятся (а ведь Вы уже слушали со всеми этими задержками, и приняли решение)?

в) Вопрос заметности. Какое смещение допустимо? Десять семплов, семпл, одна десятая семпла? Можете ответить на этот вопрос?

г) Ну если вот прям пурист-пурист, то не разбивайте стереопару на два девайса. Ну раз уж прям весь хит не создается из-за осознания того, что присутствует какой-то (какой, кстати, см. п. б) сдвиг.

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

Я завтра постараюсь сделать тестовую запись на три мика (один непосредственно на малом и два овера, на равном от него расстоянии, специально на три разных девайса засинхронизированных по сети друг с другом.
Ну и тут выложу... поищем вместе разсинхрон. Кстати, такого теста не делал - самому интересно.
 
Последнее редактирование:
@Radiator, Нельзя. Фотку я запостил где ваще никак нельзя. Мне кажется топикстартер меня проклянет если я этот оффтоп еще и поддерживать стану, сорри.
Мне был интересен механизм синхронизации двух интерфейсов по эзернету с точностю до сэмпла. Не хотел совсем чтоб это вылилось в это вот все. Глядишь щас ругань пойдет =\
Да вы то тут при чём? Вопрос правильный......... и обсуждение с вашим участием абсолютно корректное.
А мусор - почистят модераторы, попросим....
 
Ребят, вы оба встаете в позицию защитную мне кажется
Мне оно не надо, и проект интересен.

У меня был вопрос чисто технический, бо я технарь и какие-то вещщи мне просто любопытны.
Ответ (хоть и не мне был адресован)- "Часы в общем-то с точностью до пары микросекунд можно без всякого IEEE 1588 синхронизировать через 100M-сеть. " меня более чем удовлетворил.
Я думал что для этого нужны некие аппаратные средства. Мое любопытство более чем удволетворено.

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

Но вот услышу ли я сдвиг именно на 2мкс, не скажу. Это надо слушать или считать хотя бы. Сдвиг микрофона на 3-4мм слышен точно при съеме как на моей фотке на левом кабе (два микрофона в одну точку)

Александр - ваш тест ничего не даст. Оценивать запись постфактум, не слыша того что было до попадания сигнала в АЦП ничего не даст.

ЗЫ вопрос то может правильный у меня, но волна негатива поднявшаяся меня мягко говоря смущает.
 
Последнее редактирование:
г) Ну если вот прям пурист-пурист, то не разбивайте стереопару на два девайса. Ну раз уж прям весь хит не создается из-за осознания того, что присутствует какой-то (какой, кстати, см. п. б) сдвиг.
не, тут вы что то не то говорите мне кажется.
на сколько я понимаю один интерфейс будет плавать относительно другого на эти 2мкс (допустим),это же не фиксированная задержка - это ошибка синхронизации? Вы же клоки время от времени синхронизируете наверное?
Иначе, если это железобетонная константная задержка, это все вообще не имеет смысла обсуждать (при мониторинге через DAW) Я думал это очевидно.
 
  • Like
Реакции: Long
Сдвиг микрофона на 3-4мм слышен точно при съеме как на моей фотке на левом кабе (два микрофона в одну точку)

Так на 3-4 мм где-нибудь в районе приклейки купола слышно в одном микрофоне. Там сильно сказывается эффект неточечного источника и неточечного съема. И ничего, живут с этим ))))
 
Так на 3-4 мм где-нибудь в районе приклейки купола слышно в одном микрофоне. Там сильно сказывается эффект неточечного источника и неточечного съема. И ничего, живут с этим ))))
боюсь не прочитали вы мое сообщение таки.
 
@buncker, у Дмитрия есть некий посыл считать свои решения верными.... от сюда возможно и кажущаяся защитная реакция...., тем более когда начинается офтоп от @digilab2, с непонятной поддержкой Лонга...
У меня же всегда более чем конструктивный подход к любой критике или даже теоретической проблеме... я крайне заинтересован в отсутствии каких либо проблем в финале этого мероприятия и ежедневно проделываю десятки тестов...

Александр - ваш тест ничего не даст. Оценивать запись постфактум, не слыша того что было до попадания сигнала в АЦП ничего не даст.
Какой же тест может выявить величину плавающего клока на разных девайсах, который может повлиять на звук?
Не в качестве защиты, а чтоб выяснить есть ли реальная проблема или она только теоретическая.
 
Вы же клоки время от времени синхронизируете наверное?

Раз в 1мс, если быть точным. В сто раз быстрее, чем допускает IEEE 1588. Объективно там ещё есть систематическая погрешность, которую мне было лень компенсировать (порядка 7мкс, если мне не изменяет память). Когда-нибудь сделаю компенсацию для красоты.
 
  • Like
Реакции: buncker
@buncker, у Дмитрия есть некий посыл считать свои решения верными.... от сюда возможно и кажущаяся защитная реакция...., тем более когда начинается офтоп от @digilab2, с непонятной поддержкой Лонга...
У меня же всегда более чем конструктивный подход к любой критике или даже теоретической проблеме... я крайне заинтересован в отсутствии каких либо проблем в финале этого мероприятия и ежедневно проделываю десятки тестов...


Какой же тест может выявить величину плавающего клока на разных девайсах, который может повлиять на звук?
Не в качестве защиты, а чтоб выяснить есть ли реальная проблема или она только теоретическая.

я понимаю, но получается что я пытаюсь что то продавить или доказать.
пишу про съем двумя микрофонами в одну точку, и соотвественно сдвиг (плавающий) первого микрофона относительно второго, Дмитрий этого не видит и отвечает про сдвиг микрофона относительно динамика и типа живут с этим люди.... Такой себе перпендикулярный ответ не относящийся к вопросу вообще =)

Тест какой сделать я на вскидку не скажу. Надо же понимать что все что я пишу это предположения, причем достаточно осторожные.

Первое что пришло в голову - можно взять два интерфейса, подать им на вход синус килогерц в 10-15 допустим с (обязательно) одного источника. Записать это все, инвертировать фазу на одном из треков и смотреть как вычтется? Такое себе повторение ситуации в лоб.
А может свип (вернее генератор качающейся частоты)?
Хрен знает....

ЗЫ подавать синус одновременно и записывтаь с двух интерфейсов одноверемнно конечо же
 
  • Like
Реакции: Long
Дмитрий этого не видит и отвечает про сдвиг микрофона относительно динамика

Я вижу, конечно, я к тому, что там кроме гребенки из-за разного времени прихода масса факторов.

Записать это все, инвертировать фазу на одном из треков и смотреть как вычтется?

Ну будет разница. Какая-то. Как ее экстраполировать на реальные применения?
 
Я вижу, конечно, я к тому, что там кроме гребенки из-за разного времени прихода масса факторов.
ну, вот лично я ловлю нужную мне гребенку. Какие там еще факторы есть - мне не хватает ни опыта ни опытной базы выложить тут как готовое решение. Все что я могу сказать что есть реальные области применения где гуляющая гребенка будет браком и поводом дял криков в сети "этот интерфейс не звучит".

Ну будет разница. Какая-то. Как ее экстраполировать на реальные применения?
вероятно имеет какой то смысл сделать какие-то тесты (может и то что я пердложил сгодится), и посмотреть что получится.
если получится разница на пороге слышимости - то ежу понятно как экстраполировать.

Если это слишком трудозатратно, а результат не соизмерим с затратами, то опять же понятно куда надо послать мои предположения и опасения вместе с ними )))
в конце концов это всего лишь форум.
 
  • Like
Реакции: Long
на сколько я понимаю один интерфейс будет плавать относительно другого на эти 2мкс

-- Оно будет плавать на некоторую заранее не предсказуемую величину.
Т. е. если сегодня оно (к примеру) разошлось на 2 мкс, то завтра, включив аппарат
заново, может оказаться и (-3) мкс.


Я завтра постараюсь сделать тестовую запись на три мика ... специально на три разных девайса
засинхронизированных по сети друг с другом.

-- Не надо мика. 20 кГц на вход - вполне достаточно.
 
Устройства, синхронизированные только по клоку - неважно, WC или
экстрагированному из Ethernet - будут работать с одной и той же частотой
дискретизации, т.е. синхронно.
Но это не будет синфазно, т.к. сам момент старта преобразования в АЦП - он
никак, АБСОЛЮТНО НИКАК, не привязан ни к чему вообще.
Да и привязываться ему просто не к чему - я ж писал уже:
>все очень спешили в кассу, на тщательное обдумывание время тратить не хотели.

дык Дмитрий написал же про 2мкс.
Перезапустить АЦП - то уже дело совсем не сложное.
Достаточно ли 2мкс точности старта одного ацп относительно другого - это вопрос на который можно воевать уже, да. Но надо ли оно тут?
Это некая данность для данной технологии, и воюй не воюй - ничего не изменится.
Да и для 95% будущих юзеров это не буде тпроблемой бо будут юзать только один дивайс.
 
Но это не будет синфазно, т.к. сам момент старта преобразования в АЦП - он
никак, АБСОЛЮТНО НИКАК, не привязан ни к чему вообще.

Что за бред? Вы что, разницы между PLL и FLL не понимаете? Конечно я синхронизирую именно старты АЦП. Да, изменяя частоту локального генератора. Т.е. Phase Locked Loop.
 
Да и для 95% будущих юзеров это не буде тпроблемой бо будут юзать только один дивайс.
А для оставшихся 5% возможной проблема станет только в случаи вашего примера с комбиком, когда итоговый тембр сильно зависит от этой разбежности - и то, только в случаи микрофонов воткнутых в разные девайсы не ясно зачем.
Для барабанной установки действительно одного 8-и канального девайса не хватит, но будет ли реально слышимая проблема - похоже, что нет, раз вы от теста с оверами отказались.
 
Для барабанной установки действительно одного 8-и канального девайса не хватит, но будет ли реально слышимая проблема - похоже, что нет, раз вы от теста с оверами отказались.

Я писал не так давно все казино (барабаны, бас, две гитары) с румами, причём румы были в другой девайс относительно оверов и ближних миков. Ну ничего там такого сверхстранного не увидел. Наиграли, конечно, той ещё фигни, но на хит не повлияло :D
 
А для оставшихся 5% возможной проблемой станет только в случаи вашего примера с комбиком, когда итоговый тембр сильно зависит от этой разбежности - и то, только в случаи микрофонов воткнутых в разные девайсы не ясно зачем.
Для барабанной установки действительно одного 8-и канального девайса не хватит, но будет ли реально слышимая проблема - похоже, что нет, раз вы от теста с оверами отказались.
Вот честно - как на духу. - я технарь. Хвастаться не хорошо но какой-то опыт имею, иногда вижу какие-то возможные проблемы.
Ваш дивайс - будущая коммерция, и вы сейчас в стадии разработки, учесть\поправить можете все что угодно.
Если я написал фигню и бред, ну и ладно.
Если есть зерно разумное, может что-то и улучшите\поправите. Не зря день прошел, не зря на форум написал.

Итого, цели доказать что-то не имею.

и вот это мне кажется не уместно
но будет ли реально слышимая проблема - похоже, что нет, раз вы от теста с оверами отказались.
бо реально выглядит будто я вас тут троллю, и в конце концов соскакиваю с некоего кровавого спора. Даже обидно немного...

И если уж на то пошло - вы реально хотите чтоб я по записи сделанной где-то, кем-то, как-то, попытался услышать БЫЛА БЫ ОНА ДРУГОЙ еслиб ее записали на другой интферфейс? И доказал вам необходимость что-то чинить? Хрен знает даже... ну еслиб услышал - вы бы стали что-то чинить? ))))

ребят вы чего? ))
вы слушая компакт диск определите это овера криво стояли или потолок в студии зеркальный и звенит или рядом газонокосилка ездила или кто то сварочный аппарат приволок в соседнюю комнату? )))
 
Последнее редактирование:
  • Like
Реакции: Long
-- Не, все цифры тут чисто иллюстративные, от балды - бо непредсказуемы принципиально.
Каждый следующий (пере)запуск от внешней синхронизации - сдвигает момент старта
преобразования абсолютно произвольно:

Если Дмитрий сказал что может доставить сообщение из одного интферфейса в другой (тобишь синхронизировать) в пределах 2мкс (с точностью 2мкс), то какой повод ему не верить?

Из ваших сообщение нет уверенности что вы понимаете суть.
Утрированно получается так
Есть две звуковые карты - ведущая и ведомая
При старте они договариваются кто из них мастер (АЦП молчат)
После этого мастер запускает свой АЦП и посылает сообщение "я запустил АЦП" другой (ведомой) карте.
Это сообщение доставляется по 100мегабитному эзернет линку за 1-2мкс (2мкс максимум, по словам Дмитрия) иведомая карта запускает свой АЦП по этому сообщению
Итого ведомый АЦП всегда запускается не позднее чем через 2мкс после ведущего.

Не вижу тут проблемы
 
Вот честно - как на духу. - я технарь. Хвастаться не хорошо но какой-то опыт имею, иногда вижу какие-то возможные проблемы.
Ваш дивайс - будущая коммерция, и вы сейчас в стадии разработки, учесть\поправить можете все что угодно.
Если я написал фигню и бред, ну и ладно.
Если есть зерно разумное, может что-то и улучшите\поправите. Не зря день прошел, не зря на форум написал.

Итого, цели доказать что-то не имею.
Так я же много раз в теме писал - любая конструктивная критика приветствуется!!!!
Мы же сейчас раздали больше десятка сэмплов по разным странам для выявления тех самых проблем и возможных улучшений о которых вы пишите.
И вас я поблагодарил за вопрос.
Но любой вопрос нужно доводить до конца.... на ваш взгляд (слух) этот рассинхрон в 2 мкс как то повлияют на слышимый звук?
Я это не могу оценить теоретически, мне нужны практические эксперименты, по этому и предложил тест.

и вот это мне кажется не уместно
бо реально выглядит будто я вас тут троллю, и в конце концов соскакиваю с некоего кровавого спора. Даже обидно немного...
Не хотел обидеть аж ни разу. Я имел в виду, что вы отказались от предложенного теста видимо понимая, что на нём ни чего не увидите и не услышите. Ну почему все в начале ожидают какого то негатива...... и мысли не было. Наоборот.
Ну значит нужно придумать другой тест...
Ну что толку что мы в синтетическом тесте увидим разсинхрон в 2 мкс?
А может он так же как и джитер в современных девайсах - страшен только на бумаге.

И если уж на то пошло - вы реально хотите чтоб я по записи сделанной где-то, кем-то, как-то, попытался услышать БЫЛА БЫ ОНА ДРУГОЙ еслиб ее записали на другой интферфейс? И доказал вам необходимость что-то чинить? Хрен знает даже... ну еслиб услышал - вы бы стали что-то чинить? ))))

ребят вы чего? ))
вы слушая компакт диск определите это овера криво стояли или потолок в студии зеркальный и звенит или рядом газонокосилка ездила или кто то сварочный аппарат приволок в соседнюю комнату? )))
Сергей, если обнаружиться реально слышимая проблема - мы будем думать как её чинить. На самом деле есть как, но стоит ли - в этом вопрос.
И я не предлагал своим тестом услышать кривость оверов. На полном миксе вы вообще ни чего не услышите из обсуждавшегося выше. Но при записи на три мика воткнутые в разные девайсы удара с хорошей атакой, при условии, что я очень аккуратно установлю все три мика и выверю расстояние до миллиметра, можно увидеть по форме сигнала разбежность, можно возможно и услышать смещение центра удара. А если ни чего не увидим и не услышим - так может и «испугались» зря?
 
Последнее редактирование:
На полном миксе вы вообще ни чего не услышите из осуждавшегося выше. Но при записи на три мика воткнутые в разные девайсы, при условии, что я очень аккуратно установлю все три мика и выверю расстояние до миллиметра, можно увидеть по форме сигнала разбежность, можно возможно и услышать смещение центра удара. А если ни чего не увидим и не услышим - так может и испугались зря?

если это не займет много времени - подайте на два входа разных интерфейсов запись хайгейн гитары. Только надо бы как-то чтоб на оба входа приходили 100% идентичные сигналы, то етьс лучше бы с моно выхода плеера или звуковой карыт какой, и прям разветвить грубо в лоб без всяких микшеров. Ну то есть скрутить прям провода руками или если есть - разветвитель (сплиттер) кабель 1 х моно ->2 x моно

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

Мне кажется это самое простое будет. Микрофоны это морока.
 
Итого ведомый АЦП всегда запускается не позднее чем через 2мкс после ведущего.

Да, но реальность немного сложнее. Там есть локальный генератор, который, собственно говоря, отвечает за время запуска АЦП. Разность между временем запуска локального АЦП и временем прихода пакета синхронизации (который да, привязан к моменту старта АЦП мастера) попадает на вход PID-регулятора. Это сигнал ошибки. Выход регулятора - это управление частотой локального генератора. После старта постепенно (десяток секунд, постоянная времени специально сделана большой, чтобы отфильтровать шум, связанный с дрожанием времени прихода пакета) оба генератора оказываются в синхронизме, при этом моменты выборки совпадают. Остаются только сугубо технические моменты компенсации времени прохождения пакета через сеть и его обработки.

Естественно, в пакете синхронизации передаётся и номер фрейма у мастера, чтобы у всех все совпадало в смысле нумерации семплов.

Никакой «экстракции клока из эзернета» и прочей ереси, которая Лонгу мерещится, тут нет. Банальная PLL.
 
  • Like
Реакции: buncker
Да, но реальность немного сложнее. Там есть локальный генератор, который, собственно говоря, отвечает за время запуска АЦП. Разность между временем запуска локального АЦП и временем прихода пакета синхронизации (который да, привязан к моменту старта АЦП мастера) попадает на вход PID-регулятора. Это сигнал ошибки. Выход регулятора - это управление частотой локального генератора. После старта постепенно (десяток секунд, постоянная времени специально сделана большой, чтобы отфильтровать шум, связанный с дрожанием времени прихода пакета) оба генератора оказываются в синхронизме, при этом моменты выборки совпадают. Остаются только сугубо технические моменты компенсации времени прохождения пакета через сеть и его обработки.

Естественно, в пакете синхронизации передаётся и номер фрейма у мастера, чтобы у всех все совпадало в смысле нумерации семплов.

Никакой «экстракции клока из эзернета» и прочей ереси, которая Лонгу мерещится, тут нет. Банальная PLL.

ну я нарочно утрировал, ибо мне кажется вы с Лонгом просто о разных вещах говорите. Или он не сталкивался особо с микроконтроллерами\эзернетом и экстраполирует свой опыт на эту область теряя с деталями важные моменты.

А так то понятно что АЦП тактировать прощще сразу а не ждать некоег осообщения, а потом в софте пропустить "лишние" отсчеты целиком если надо и разницу точную уже "догнать" PIDом плавно меняя клок

Я наверное в который раз повторюсь, но для меня было неожиданно что по 100мбит линку можно так точно синхронизироваться.
 

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