Боитесь, что озвучите цену, выстроится очередь, и не будете успевать справляться с поставками? 
Это некоммерческий проект.
Пугает, что ни кто не захотел сравнить или послушать…
Интересует какая ЗК, МП и т.д.
А ведь могу попросить А.Л.Балаева принять группу товарищей, чтобы сравнить с хорошим транспортом.
Так точно, интересует! Расскажите или есть желание владеть безраздельно? И ещё интересно что у Вас после транспорта?
Владелец связки Denon DP-S1/DA-S1 был сильно удивлен.
Марат @Cu6apum, буду рад, если вы возьметесь прояснить:
Как технически выглядит джиттер при аналоговой передаче цифрового сигнала, понятно. Но хотелось бы понять, каким образом этот джиттер «пролезает» в ЦАП в случае асинхронного приема цифры, при котором за счет работы внутреннего клока ЦАП-а формируется новая временнáя сетка, благодаря которой пришедшие нули и единицы заново должны выстраиваться в правильном порядке с четко выверенной частотой. То есть выглядит так, как если бы джиттер, дошедший до ЦАП-а в аналоговой форме, создавал в ЦАП-е причины (помехи) для возникновения внутреннего джиттера в самом ЦАП-е, проявленного прямо пропорционально степени проявления внешнего джиттера. Тáк это работает?
Я это один раз расталдыкаю, ок? 
Потом можно ссылаться.
Аудио по usb передается в изохронном режиме, т.е. источник плювает пакеты данных с заданным интервалом. Точностью его соблюдения он и характеризуется: на нетбуках с этим хуже всего, а десктоп с кучей корневых хабов и мощным мостом обычно не испытывает проблем с загруженностью usb-контроллера.
Изохронных режимов два: синхронный и асинхронный. Первый я всерьез рассматривать не хочу, это полная беда: источником битклока является комп, при этом джиттер достигает запредельных величин, а выпадения фреймов приводят временами к оглушительным артефактам и, в пределе, к похоронам пищалок. В природе подобные цапы в качестве маркетингового курьеза еще встречаются, но включать их по usb я не советую вообще совсем, кроме шуток.
Асинхронный режим свободен от джиттера по данным настолько, насколько соответствуют стандарту контроллер и хаб на передающей стороне и приемник. Если они исправны, фрейм долетает до последнего и при наличии места в очереди садится в ее хвост. При отсутствии места приемник сигналит компу о переполнении и тот приостанавливает передачу.
Цап забирает семплы из головы очереди по собственному клоку, поэтому джиттер по данным минимизирован до величин фазового шума генератора и цепи дистрибуции синхросигналов.
Казалось бы, все безупречно. Но. Если контроллер или комп сильно загружен (скажем, на хабе сидят и цап и внешний винт, либо же на компе стоят форточки и им приспичило почесаться в другом месте), очередь может истощиться из-за большой задержки с поступлением свежих данных. В этом случае мозги цапа имеют всего два выхода: либо гнать на преобразователь последний валидный семпл, надеясь на скорое пополнение очереди, либо встать в mute во избежание громкого пука. Первый расклад ведет к искажению сигнала, второй - к запинке воспроизведения.
А теперь засада. Учитывая квази-реалтаймовую отдачу инфы, драйвер на передающей стороне может просто похерить потерянные во время истощения очереди данные, чтобы не вылезти из тайминга трека. Я такое встречал в видеоплеерах, картинку-то не притормозишь. В итоге трек просто перескакивает через паузу, как иголка в соседнюю канавку на запиленной пластинке.
Для решения проблем с запинками, в мозгах цапа обычно делают очередь на несколько сотен, а иногда и тысяч семплов, чтоб не зависеть от скорости компа. Но на набивку очереди тоже уходит время (протокол-то изохронный), посему в тех же видеоплеерах приходится поиграть значением lip sync, чтоб губа попадала в фанеру. Latency.
Продвинутые usb-приемники имеют детектор среднего и пиковых отклонений частоты подачи данных со стороны компа и могут предикативно регулировать размер очереди, дабы соблюсти баланс между latency и риском опустошения очереди, у них задержки пренебрежимо малы.
Как видите, в асинхронном режиме понятие джиттера относится только к потрохам цапа. Передатчик и приемник usb, будучи исправны, сами разбираются с внутренностями протокола и его физикой, не вмешивая в это оконечные устройства. Синхронный же режим для прослушивания музыки непригоден в принципе.
Спрашивайте.
29 лайков
Спасибо. Теперь стал вполне осязаемым ваш тезис относительно того, что все артефакты, привносимые USB-кабелем в аудио тракт, имеют исключительно “антенное” происхождение.
1 лайк
Поэтому в той же Tiny все силы брошены на то, чтобы RT-ядро вовремя выдавало данные на USB шину с минимальной задержкой, а остальные процессы не мешали этому и ими занимались другие ядра процессора.
Ну я ж не с кондачка что-то утверждаю. Знаю - делюсь, нет - спрашиваю умных.
4 лайка
Марат, а как объяснить утверждение что цифра с СД играет “аналогово”, “слитно” и.т.д., а по ЮСБ звук “резкий” и “плоский”? Возможно ли получить аналогичный эффект на ЮСБ?
В мемориз!
Те источник посылает по проводу сигнал (меандр?) который на приемнике принимается без проверки и бьется клоком в цифру 0 и 1? Может ли случится так что помехи или другие факторы могут с одной временной периодичностью искажать сигнал так что мы будет получать вместо нулей единицы и соответственно искаженный сигнал в итоге, который не будет восприниматься как выпадения или шум а именно как изменение?
Нет, не может. Могу объяснить почему, но уверен - Марат это сделает лучше
1 лайк
Сорри, что вмешиваюсь, но в изохронном режиме приемник все равно проверяет CRC, хотя и не запрашивает битый пакет повторно (link):
Isochronous transfers are used to transfer data in real-time between host and device.
When an isochronous endpoint is set up by the host, the host allocates a specific amount of bandwidth to the isochronous endpoint, and it regularly performs an IN- or OUT-transfer on that endpoint. For example, the host may OUT 1 KByte of data every 125µs to the device. Since a fixed and limited amount of bandwidth has been allocated, there is no time to resend data if anything goes wrong. The data has a CRC as normal, but if the receiving side detects an error there is no resend mechanism.
2 лайка
Очень хорошо написал Гордон Ранкин про USB - с примерами. Скриншотами. Там и тема кабелей затронута - “которые не влияют же”.
2 лайка
Попробовал разобраться как оно работает, но мозг закипел))
А если контрольная сумма не совпадает то пакет данных пропускается? И на сколько влияет на звук пропуск пакета данных?
Короче, пока сам не измеришь, будешь пребывать в дурмане религиозного аудиофильства, полагаясь лишь на мнение аудиофильских гуру - того или иного, в зависимости от секты.
Единственное, что бесспорно - USB кабели на звук влияют и влияют ярко выражено.
Кто-то, конечно, спорить будет. Но какой от этого толк? Никакого, когда результат налицо.
2 лайка
digital glare
Как указал Марат, есть два варианта - либо пропуск, либо дублирование предыдущего целого. Зависит от реализации приемника.
Вообще-то, наиболее показательна передача формата DoP. Битый маркер должен приводить к переключению режима, тогда как пропуск пакета - к треску.
2 лайка
Ссылка вообще ниачём. Воду в ступе толкут бессмысленно. Главная мысль - хорошие usb-кабели зто хорошо и пропусков пакетов нет, а плохие - это плохо и в результате могут выпадать пакеты. Спасибо, а мы-то были не в курсе!
Марат о сути вопроса дал чёткую информацию в 5 раз короче и в 10 раз лучше.
6 лайков