Psy Prog писал(а):
Да как это линия связи не причём? А во чём же по вашему джиттер возникает?
Джиттер возникает в устройствах обработки. Физические линии передачи, как правило согласованы и не вносят существенного влияния в картину.
Psy Prog писал(а):
Да, конечно, можно реализовать протокол, как описано в том пдээфнике, но вобщето Джулиан Дан преследует несколько иную цель: а именно организацию передачи аудио/видеоданных от АЦП к ЦАП в режиме реального времени. И между прочим, все измерения и графики в статье - мифические, в смысле это компьютерное моделирование.
По поводу компьтерного моделирования - это в данном документе компьютерное моделирование. В других есть и реальные измерения. Просто этот более или менее просто написан по теме джиттера.
Целей там несколько, и одна из них - ASRC - как раз относится к передаче данных по асинхронному каналу с независимой синхронизацией, которым и является TosLink (S\PDIFF).
Psy Prog писал(а):
А теперь рассмотрите S/PDIF как обычный асинхронный последовательный интерфейс передачи данных. Вот, например, RS-232 у Вас в компьютере (надеюсь не надо клясться на крови, что он может работать в асинхронном режиме?) прекрасно работает вплоть до 115 Кбит. Скажите медленно? Ок, возьмите 485. А всё потому, что и передатчик и приёмник имеют каждый собственный задающий генератор. Опять скажите что они не синхронизированы? Нет. Не синхронизированы. А нафига?
Ну что ж... Значит придется пересказывать статью...
Дело в том что по асинхронным компьютерным интерфейсам передаются асинхронные же компьютерные данные. Т.е. источник может "подождать", когда передача осуществится полностью. И здесь, конечно, разница в наносекунды роли большой не играет. В "музыкальных" интерфейсах возможность повлиять на скорость прихода данных с того же CD привода отсутствует. А это значит, что синхронизировать-то и нечего (в iLink как раз эта функция и введена). И это же значит, что сколь не был бы велик буфер, возможна ситуация, что бОльшая скорость прихода данных, отличающаяся на единицы герц от скорости передачи его переполнит.
Кстати, что касается синхронизации - это Вы хватанули. Если мы будем рассматривать "полный" RS-232 (а это семь проводочков), то там есть цепи готовности передатчика и приемника и цепи подтверждения их освобождения. В "неполном" RS-232 никто Вам не гарантирует полной скорости передачи - это раз, во-вторых, как правило, присутствуют XON/XOFF, которые работают синхронизаторами потоков. И опять же, на физическом уровне есть выделенные старт-стопные биты, синхронизирующие, в некотором смысле скорость передачи/приема. Ну, и куча практически безграничных буферов с двух сторон. А так - никакой синхронизации.
Psy Prog писал(а):
Да, при таком способе передачи, данные, накопленные во входном регистре приёмника "отстают" на величину, равную разнице в фазе задающих импульсов плюс затяжка фронта импульса данных, а это наносекунды. И входгой буфер у Вас в ресивере достаточный, потому как S/PDIF обслуживае совершенно другая микросхемина, нежели ЦАП, хотя она и может его содержать. И порт в десатибаксовой карточке работает точно на частоте, потому как все нормальные кодеки тактируются от кварца.
Собственно, все вышеприведенное Вами, только некоторая идеализация реальных процессов. Передача данных происходит аналоговым способом (подверсия фазовой модуляции, допустим, для S/PDIFF - см. опять же те же ссылки). А это значит, что помимо задающего генератора есть аналоговые фазосдвигающие цепи и прочее. Аналоговые вещи гораздо тяжелее в реализации, и гораздо дороже. Собственно, поэтому качество карточки влияет на результат. Ошибки возникают при множественных преобразованиях, фазовых подстройках (которые построены по интегральному принципу - а это значит имеют некоторую плавающую дельту), из-за разностей в скоростях поступающих и обрабатываемых потоков, причем плавающих и пр.
Собственно, не было бы проблемы, не было бы и упоминания о ней. Не было бы необходимости изобретать пути их (проблем) решения. То, что Вы пытаетесь оспорить существование проблемы не исключает ее. Я, например, несколько лет назад сел и сам, пользуясь своими знаниями, все это просчитал. И понял, что проблема не так велика, но существует и может приносить свой отрицательный вклад в передачу не обязательно музыкального, но любого real-time контента. С тех пор эти мои догадки (я не претендую на научность своих изысканий) много раз подтверждались и когда мы начали предоставлять Voice-over-IP и когда пошли online трансляции real-time потоков (аудио и видео)...
)
