Опять загадочный экслюзив имени "уши лихницкого"
Нигде кроме, как у меня и в газпроме…
Ну и смысл писать, что мол есть у меня такие приборы, но мы вам о них не расскажем.
Виталий. Ты же слышал его у меня в системе…
И что, Ваш источник разорвал Krell KPS 20i который там на фото стоит? (хоть это и не чистый транспорт, а полный плеер, и это не самый топ у фирмы). Или файловый был в сравнении с этим CD не так уж плох, поэтому хозяин решился его взять?
Сколько же тогда определили цену за своё изделие? (прикидывая стоимость этого Крилла, если он и вправду был повержен).
Вы видимо перепутали с другим, у меня ник V на более светло-зеленом фоне.
Увы в моей округе сильных источников цифры не наблюдается, CD не счет
Да этот Krell, а до этого стоял топовый Изотерик. Цену спрашиваете с целью приобретения?
Извиняюсь. Действительно напутал.
Боитесь, что озвучите цену, выстроится очередь, и не будете успевать справляться с поставками? 
Это некоммерческий проект.
Пугает, что ни кто не захотел сравнить или послушать…
Интересует какая ЗК, МП и т.д.
А ведь могу попросить А.Л.Балаева принять группу товарищей, чтобы сравнить с хорошим транспортом.
Так точно, интересует! Расскажите или есть желание владеть безраздельно? И ещё интересно что у Вас после транспорта?
Владелец связки 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 лайка