Еще раз об adat и clock.

  • Автор темы Автор темы Devian
  • Дата начала Дата начала
ну возможно они синхрятся по тб например как аполло
-насколько знаю usb и tb синхрят в пределах одного интерфейса( точнее usb вообще ничего не синхрит т.к генераторы или синтезатор
с фапч находятся в самом интерфейсе, про tb не знаю но я думаю примерно тоже самое) , более одного это wc или src
 
Последнее редактирование:
-если интерфейсов больше одного то правильная синхра возможна только по wc иначе будет разьезд по фазе на вч

А если один интерфейс с master clock имеет две пары adat входов/выходов, то к нему ведь можно повесить два AD по adat и отправить в каждый клок тоже по adat. Вроде бы это валидная схема, нет? Получится три устройства под синхронизацией.
 
@Aleksandr Oleynik, не пойму в чем таком прав @Andrey Ivanov, и в чем не прав я. При этом частный случай от @Rst7, как бы намекает на то, что оказывается и такое бывает. Я бы не писал эти глупости если бы сам не столкнулся с подобным. Тот самый случай когда стабильность синхронизации сохранялась только в том случае, когда мастером выбиралось только одно конкретное устройство. И это не тот случай когда устройств только два или три.
 
А если один интерфейс с master clock имеет две пары adat входов/выходов, то к нему ведь можно повесить два AD по adat и отправить в каждый клок тоже по adat. Вроде бы это валидная схема
да, валидная. здесь прекрасно работает.
 
"There are many circumstances in which a sample clock
must be derived from an external source. In a digital audio
recorder or a digital surround processor, for example, the
sample clock controlling the DAC is extracted from the input
data stream. In other applications the sample clock of an
ADC might need to be locked to an external sync signal, or
a digital data stream might need to be resynchronized to a
different clock reference using an asynchronous sample rate
converter (ASRC).
This external clock source may well have jitter, but that,
by definition, is not sampling jitter. The external source
might make a contribution to the sample clock jitter, but that
contribution depends on the characteristics of the clock
recovery circuit (or numerical algorithm) between the
external source connection and the actual (or virtual)
sample clock. This will have intrinsic jitter, jitter attenuation,
and jitter non-linearities in its behavior."

 
  • Like
Реакции: Devian
@digilab2, аполло позволяет каскадировать девайсы без всяких синхронизаций по тб, значит все как то реализовано
 
не как то, а через ТБ.
-ну может быть я в tb не силен может там в протоколе есть спец синхросигналы , usb точно не синхрится
да мне вообщем это и неинтересно , т.к все равно генераторная часть почти у всех интерфейсов ниже плинтуса
из того что было исследовано кроме лаври голд и еще чего то не помню уже
 
@digilab2, какая проблема передать в общем пакете данных ещё и синхро сигнал?
Как синхронизируются три RME PCI-E карты, которые агрегируются в один драйвер?
 
@Aleksandr Oleynik, не пойму в чем таком прав @Andrey Ivanov, и в чем не прав я. При этом частный случай от @Rst7, как бы намекает на то, что оказывается и такое бывает. Я бы не писал эти глупости если бы сам не столкнулся с подобным. Тот самый случай когда стабильность синхронизации сохранялась только в том случае, когда мастером выбиралось только одно конкретное устройство. И это не тот случай когда устройств только два или три.
Так нужно просто рассмотреть конкретный случай и разобраться, что было не так.
Все мои эксперименты с кучей железа с WC и с отдельным WC генератором говорили всегда о том, что вообще по барабану, важно чтоб мастер был один и чтоб остальные получили синхру WC.
Если и было что то не так - ругался какой то девайс на отсутствие синхры, то я сам был дурак, или шнурок отвалился или частоту не верно поставил. К моему удивлению не все девайсы понимают WC и переключают свой на нужную частоту. Возможно не все и сообщают о том, что не получают WC по какой либо причине.
 
  • Like
Реакции: itzh
@digilab2, какая проблема передать в общем пакете данных ещё и синхро сигнал?
-так он как бы и в spdif есть толку то от него, да устройства( цап) при этом работают верно , но фаза аналога на вч практически
всегда не совпадает( проверено неоднократно), как только делается синхра по wc все совпадает, т.е отсюда банальный вывод
что синхрится должны сэмплы а не мастер клок
 
Как синхронизируются три RME PCI-E карты, которые агрегируются в один драйвер?
в винде понятия не имею если там вообще такое есть, в маке скорее всего через src, хотя я не знаток данной темы, да и
не особо интересна
-единственое могу сказать что есть например атомные часы со стабильностью 10-11 10-12 , так вот если их между собой не
синхрить то они тоже рано или поздно начнут давать ошибку относительно друг друга , правда там ждать придется
довольно долго
 
Последнее редактирование:
Исключительно при помощи физической синхронизации по WordClock, ADAT, AES - так же, как все автономные внешние приборы!
Я о PCI-Ex картах спрашивал... но там кажется на самой карточке есть шнурки.
 
-так он как бы и в spdif есть толку то от него, да устройства( цап) при этом работают верно , но фаза аналога на вч практически
всегда не совпадает( проверено неоднократно), как только делается синхра по wc все совпадает, т.е отсюда банальный вывод
что синхрится должны сэмплы а не мастер клок
Мы сейчас по второму кругу пойдём.
Обсудили же, что не важно от куда в девайс прийдёт мастер клок, или по физ шнурку WC или по любому из цифровых каналов, важно чтоб он пришел.
Плавать фаза может, на сколько я это понимаю, исключительно между синхро импульсами или если синхро сигнал сам по себе смещен по тем или иным причинам и услышать это можно только записав моно сигнал одинаковый на два разных девайса, т.е. ни когда в реальной жизни.
 
Попробую спросить иначе.
Есть два аудио интерфейса, оба подключены к компьютеру по TB или USB. Оба выполняют функцию AD, но только один выполняет функцию DA на мониторы. Кто из них должен быть Master, а кто Slave? И почему, если не сложно, можете пояснить?
А нафига их синхронизировать?!
 
А нафига их синхронизировать?!
Если не синхронизировать, то будет SRC программный, мягко говоря джитеры и прочие шумы клоков покажутся детским лепетом.
Ну все эти вопросы касаются конечно только Мак Юзеров, ну или тех, кто юзает ASI4ALL, потому как кажется только он позволяет агрегировать девайсы на Винде.
 
@dromax, а вы прям всё из написанного в этой ветке знаете и понимаете?
Я сейчас попрошу @Rst7 вам пару вопросиков на засыпку задать. ;)
Уверяю вас, что даже после прочтения внимательного данной темы народ будет продолжать сильно плавать в вопросах клока, особенно те, кто на Маке.
 
  • Like
Реакции: itzh
Если не синхронизировать, то будет SRC программный, мягко говоря джитеры и прочие шумы клоков покажутся детским лепетом.
Ну все эти вопросы касаются конечно только Мак Юзеров, ну или тех, кто юзает ASI4ALL, потому как кажется только он позволяет агрегировать девайсы на Винде.

Ну кстати, если критически к этому отнестись. Работа src может остаться совершенно незамеченной, если пользователя заранее не предупредить, что она есть и она портит звук
Не так уж там всё страшно на самом деле
 
Если не синхронизировать, то будет SRC программный, мягко говоря джитеры и прочие шумы клоков покажутся детским лепетом.
Ну все эти вопросы касаются конечно только Мак Юзеров, ну или тех, кто юзает ASI4ALL, потому как кажется только он позволяет агрегировать девайсы на Винде.
При этом Вы защищали ненужность клока в разрабатываемых сетевых интерфейсах.
 
@dromax, ну вы прям крутой мужик тут все за всех определили. Так поделились бы чем понты колотить. Где еще информацию брать? Зачем тогда форум?
 
А как можно иначе завести в DAW два девайса выполняющих AD?
Если перечитаете повнимательнее пост на который была реплика, то увидите там далеко не два AD, а цепочку AD - Комп - DA. Не вижу особой необходимости.

PS. А вот разработчики ip интерфейса и в Вашей схеме не видят проблем. Хотя вот высказался наконец представитель группы, что джитер покажется лепетом детским.
 
Последнее редактирование:
При этом Вы защищали ненужность клока в разрабатываемых сетевых интерфейсах.

Если Вы про наши девайсы, то защищали ненужность BNC-разъема с WC. Сами по себе девайсы внутри сети отлично синхронизируются без всяких дополнительных шнурков.
 
Если Вы про наши девайсы, то защищали ненужность BNC-разъема с WC. Сами по себе девайсы внутри сети отлично синхронизируются без всяких дополнительных шнурков.
Спасибо, понятно. Проблема лишь в установке разъема.

PS. Но, может, синхронизация и суть WC не совсем одно и то же?
 
PS. Но, может, синхронизация и суть WC не совсем одно и то же?

Если Вы про наш случай, то у нас не совсем одно и то же. Т.к. нам надо синхронизироваться не только с точностью до семпла, но и с точностью до пакета данных. Чтобы все девайсы отправляли пакеты с данными с одним и тем же начальным номером семпла. Что, понятное дело, при WC невозможно. Потому проблема не только "лишь в установке разъема".
 
Если Вы про наш случай, то у нас не совсем одно и то же. Т.к. нам надо синхронизироваться не только с точностью до семпла, но и с точностью до пакета данных. Чтобы все девайсы отправляли пакеты с данными с одним и тем же начальным номером семпла. Что, понятное дело, при WC невозможно. Потому проблема не только "лишь в установке разъема".
Да, и это было изначально понятно. Кстати, а как Waves вышли из положения?
 

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