Почему нет, если к родному цапу Тотал Дак подключить, должно играть. Цап слушал - бомба. Жалко, что нет у фирмачей i2s и жалеют устанавливать входа для внешнего клока. Опять впендюрили RCA на выход spdif вместо bnc. Блин, ну за 7 косарей зелени все входа-выхода должны быть! Хорошо хоть Spdif Pro есть (AES) - но все равно, композитный это сигнал, со всем вытекающим джиттером. Компонентный i2s зажилили 
2 лайка
Поставить 75-и омный терминал WBT, и делов-то…Будет лучше BNC из непонятного материала.
Кстати, никаких переделок для этого не нужно? Хочу заменить в одном аппарате rca на bnc.
Не нужно. Только не вижу смысла особо из-за того, что непонятно качество терминалов BNC, одно время плотно искал качественные, брендовые, типа Фурутек, Ойяд, и т.д.- ничего не нашёл, одна дешёвка в лучшем случае из грязной латуни.
2 лайка
Дык кабель RCA будет и в ЦАПе нужно соответствие, тут один терминал не поможет, вся линия должна быть. Ну хоть AES есть, и то ладно.
Да не должны, I2S изначально для внутренней передачи между рядом стоящими элементами схемы, а не для выводы сигнала наружу…
8 лайков
Доброе утро, европейские производители, на дворе 2025 год))
Давно придуман LVDS, то есть балансный i2s, рядом стоять не требуется.
2 лайка
Абсолютно верно! С увеличением длины кабеля больше 5- 10 см протокола I2S возникают другие проблемы, у меня опыт не очень хороший с соединением I2S! Маркетолухи в тренде как всегда 
6 лайков
Каталог монументальных кастрюль 
У производителей есть общепринятые стандарты, S/PDIF и AES/EBU. Им достаточно. И нет нужды в самодеятельности, тем более при (относительно) массовом производстве.
3 лайка
В пустую истратили столько металла, оставили углеродный след - глупо и никчёмно
1 лайк
У производителей есть общепринятые стандарты, S/PDIF
Ну да, нет нужды, и так сойдет ведь. Интересно, в каком стандарте принято ставить RCA разъемы на S/PDIF ))
1 лайк
Проехавший мимо КАМАЗ наносит вред экологии больше чем все производители CD-транспортов вместе взятые))
7 лайков
Юр,это точно не I2S кабель,это больше на кабель питания похоже,а I2S плоский кабель обычно.
Lvds это интерфейс передачи сигналов, как и spdif, и он тоже имеет джиттер. Более того, хорошие приемники спдиф могут убрать джиттер линии, а LVDS не может этого сделать по определению (из-за технической реализации линии передачи).
I2s через lvds ничем не лучше спдиф если не будет делаться реклок всех сигналов с обратной синхронизацией … а он не делается в 99% случаев.
Действительно… 21 век на дворе, а у Кота Базилио по-прежнему много работы 
4 лайка
Я этот сидюк разбирал и делал из него транспорт. То есть отключал цап.
Там питание на цап другие провода. Это как раз связь цифровой части и цап. Других проводов между ними нет. А так да, толстые. Я тоже сначала думал питание.
Возможно вот этот имели ввиду. Это той же фирмы сидюк, но другая модель. Но и там где то 50 см.
3 лайка
Спдиф он сам по себе ущербный и ему ничто не поможет. Реклок тоже не выход - он одно лечит, другое калечит. А подробнее про всё это под спойлером.
Спойлер
The trouble with S/PDIF is that there is no clock to tell the receiver when data needs to be sampled. The data and the clock are all baked into one line. Protocols are used to extract the clock and data but the extraction process uses an adaptive, ever changing process, usually based on PLLs. This results in the opposite of clock stability, what’s required for low jitter. Essentially the S/PDIF receiver doesn’t know when what’s coming next is actually going to come next, it knows roughly when this is going to occur but there’s nothing it can rely on, so they use a tunable PLL that can vary its frequency accordingly to match the rate at which the data is output as closely to the rate at which the data is input. Obviously there are buffers involved, so if the buffer starts to run empty, or starts to fill up too quickly the output data rate is adjusted to there isn’t any break in the data stream, but PLLs don’t have the same kind of clock stability required for ultra low jitter performance as oscillators do. I make it sound far worse than it is, it’s not like you can perceive the changes in the PLL shifting as changes in pitch (like Alvin, Simon and Theodore up above), everything runs in a stable fashion, but the quality of the clock that the PLL can create is limited by the inherent limitations of PLLs so although the data gets there it does so with additional jitter versus what came out of the original box.
Effectively, with S/PDIF we’ve broken the link back to our ultra high quality master clock oscillator in our CD player and are now forced to do some nifty tricks to create something similar again. It’s not just less than ideal it’s a shambles in terms of what you don’t want to be doing but it’s simple and works. As an aside jitter is only an anomaly that crops up during data playback in real time . If you were a sound/recording engineer and used S/PDIF to transmit digital audio from one device into a PC for some post processing then it would be absolutely fine. All the data would get there intact. All the ones and zeros are in the right place, it’s just that during immediate play-back, from the clocks generated by the S/PDIF receiver, you end up with subtle timing errors and those are what create jitter.
So what do you do? Why can’t we just introduce another ultra low jitter master clock at the receiver end. You can do if you want but you still need the PLL. The trouble is that even if you use another of the same ultra low jitter oscillator used in your CD player the two wont run at exactly the same speed. They aren’t synchronised, they are close, but not identical. This is where the asynchronous sample rate converter (ASRC) comes into play, in other words the ‘jitter removal’ part of what’s included in ESS DACs. These take the bit clock, LR clock and data line that is generated by your S/PDIF receiver and process it. In doing so they (in basic terms) essentially generate a software based version of what the analogue waveform would look like for the signal input into it. You then attach your ultra low jitter master clock to the output side of the ASRC. The output side then samples the software waveform and creates a new set of data. This is then output from the ASRC, you get a new bit clock, LR clock and data line timed to a new master clock of ultra low jitter and Santa comes down your chimney. Jitter be gone. So it’s perfect right? No. First of all it’s not bit perfect because the output side of the ASRC generated a brand new set of samples. Second is that (apparently) the jitter present on the input of the ASRC is simply shifted to the output in a different form. ASRCs weren’t actually invented to remove jitter, they were invented in order for two systems using dissimilar sampling frequencies to interface with one another. You might have an ADC and DSP that you want to link together. The obvious way to do this is to run one as a master and the other as a slave, but the world happens and they might both be masters, or both in entirely different boxes from one another, so the ASRC is used to allow them to talk to one another. It just so happens that ASRCs also attenuate jitter so they found themselves being incorporated inside DACs.
A very obvious way to circumvent all these jitter issues is to simply remove the S/PDIF receiver and transmit the I2S stream directly from box 1 to box 2. This isn’t simple (like S/PDIF), for a number of reasons, but if you do it correctly then it does work very well. We can see this in the measurements above with the ESS chips jitter reduction switched off. The direct I2S stream is much cleaner. It should also be bit perfect because the on-board ASRC has been disabled. I’ve done I2S over network cables myself using LVDS no problems there and you can also get transformer based LVDS systems that offer isolation between one end and the other, a bit like TOSLINK optical cable only not using the S/PDIF standard.
Русский:
Проблема S/PDIF в том, что в нём нет отдельного тактового сигнала, который указывал бы приёмнику, когда нужно считывать данные. Данные и тактовая частота объединены в одной линии. Для их разделения используются протоколы, но процесс извлечения основан на адаптивных, постоянно подстраивающихся методах, обычно с использованием ФАПЧ (фазовой автоподстройки частоты). Это приводит к противоположности стабильности тактового сигнала, которая необходима для низкого джиттера. По сути, приёмник S/PDIF не знает точно, когда поступят следующие данные — он лишь примерно представляет временные рамки, но не может на них полагаться. Поэтому используется регулируемая ФАПЧ, которая меняет свою частоту, чтобы максимально точно соответствовать скорости передачи данных. Разумеется, здесь задействованы буферы: если буфер начинает опустошаться или заполняться слишком быстро, скорость вывода данных корректируется, чтобы избежать разрывов потока. Однако ФАПЧ не обеспечивают такой же стабильности тактового сигнала, как генераторы, что критично для сверхнизкого джиттера.
Я, возможно, сгущаю краски — на слух вы не заметите, как ФАПЧ подстраивается. Система работает стабильно, но качество тактового сигнала, создаваемого ФАПЧ, ограничено её inherent limitations. Данные доходят целыми, но с дополнительным джиттером по сравнению с исходным источником.
Фактически, S/PDIF разрывает связь с высокоточным тактовым генератором в CD-плеере, заставляя нас воссоздавать нечто подобное на стороне приёмника с помощью хитрых уловок. Это не просто далеко от идеала — это полный бардак с точки зрения борьбы с джиттером. Но метод прост и работает. Кстати, джиттер проявляется только при воспроизведении в реальном времени. Если вы звукорежиссёр и передаёте цифровой аудиопоток через S/PDIF, например, в ПК для постобработки, проблем нет — все биты останутся на своих местах. Но при мгновенном воспроизведении через тактовый сигнал приёмника возникают микроскопические временные ошибки, которые и создают джиттер.
Что же делать? Почему бы не добавить ещё один сверхстабильный генератор на стороне приёмника? Можно, но ФАПЧ всё равно понадобится. Даже если использовать такой же генератор, как в CD-плеере, их частоты не будут идеально совпадать — они близки, но не синхронизированы. Здесь на помощь приходит асинхронный преобразователь частоты дискретизации (ASRC, он же «подавитель джиттера» в ЦАПах ESS). Он обрабатывает тактовые и данные сигналы от приёмника S/PDIF, программно реконструируя аналоговую форму волны. Затем к выходу ASRC подключается высокоточный генератор, который передискретизирует эту волну, создавая новый набор данных с ультранизким джиттером. Волшебство? Не совсем. Во-первых, это не бит-идентичное преобразование — ASRC генерирует новые отсчёты. Во-вторых (как утверждается), джиттер на входе ASRC не исчезает, а трансформируется в иной вид. ASRC изначально создавались не для борьбы с джиттером, а для стыковки устройств с разной частотой дискретизации (например, АЦП и ЦОС). Просто оказалось, что они ещё и ослабляют джиттер, поэтому их стали встраивать в ЦАПы.
Самый очевидный способ избежать этих проблем — вообще отказаться от S/PDIF и передавать I2S-поток напрямую между устройствами. Это сложнее (в отличие от простоты S/PDIF), но при грамотной реализации работает отлично, что видно по измерениям ESS-чипов с отключённой коррекцией джиттера: прямой I2S-поток значительно чище. К тому же он бит-идентичен, так как ASRC не активен. Лично я успешно передавал I2S по сетевым кабелям через LVDS, а существуют и гальванически развязанные LVDS-решения (аналогично Toslink, но без S/PDIF).
4 лайка
Аудио стандарт на протяжении десятилетий. Он еще всех нас переживет…
1 лайк