The iLink and jitter 'snake oil'

AVForums

Help Support AVForums:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
S

skinnyfat

Guest
My oh my its been quiet in here. - One more word from any of you and I'm afraid we'll have to ask you to leave :077:  :044:

To get you guys debating again, I came across this rambling on another forum and my initial thoughts were, well quite frankly - 'what a lot of tosh' and this is exactly what fuels the brain-washing marketing that gets the public to outlay unnecessary cash. Read on and all you professors/academics/engineers please enlighten us


Everyone who has tried i-Link with the S-Master Pro amplifiers has been very enthusiastic about it, largely because it helps reduce jitter compared with SPDIF connections, I suppose. Everyone is obsessed with jitter in digital audio systems, and synchronous (I2S) and isochronous (i-Link) connections seem to be a way of reducing it.

The problem seems to be that every element in the audio chain contributes to jitter, and it generally increases with every process and every connection. However, after reading what Steve Nugent of Empirical Audio has been saying, it suddenly occurred to me today that i-Link might not even be second best to a full synchronous connection.
The real problems appears to be that the digital audio stream contains timing data as well as sample data. The bits may get through themselves, but the timing information seems to get corrupted quite readily. This information starts with the transport clock, and everything else slaves off that. The clock (word and bit) data may be carried forwards to a DAC or AV amp using I2S connections, that relieve the bitstream of timing duty, but that only stops jitter getting worse.

I-Link is rate-adaptive connection, that uses a relatively crude closed-loop speed control algorythm (part of the A&M protocol?) to control the transferred data rate from the player or transport. The rate control is applied by the DAC or amplifier, and fed backwards to the source. This is unlike I2S where the player controls the phase by feeding timing information forwards.

What this means is that in between the "speed-up/slow-down/as-you-were" commands, the sample data in the i-Link is free-running, and does not carry any timing data. It is only where there is (inaccurate)timing data in the audio data that there can be jitter - because there is disparity from the source. The timing data is only generated within the DAC or amplifier, using the internal clock (which obviously has to be good) . The crucial timing data is no longer generated by the player - all that does is generate a stream of audio sample data.

I don't think there is any point in saying i-Link is jitterless, because there is timing corruption in all stages of digital connections, but the I think the problem with jitter is where the timing information has to be carried through so many equipments, processes and equipments that it can't help but be vulnerable to corruption.

A great light shone on me today when I realised that using I-link with my beloved DA9000ES may help to do away with all those steps. the timing information is generated in the amp itself, and the amp is the DAC itself. There will always be some jitter, because even the IEEE 1394 receiver will generate some, but really jitter has no-where to go. I always knew my amp was wonderful, but it never occurred to me that it wasn't worse than a combo with an I2S connection.

I haven't fitted the Superclock 3 to my Pioneer Dv989AVi yet , but I'm bursting to do that next week (while the family are away) as that will show no improvement using the i-Link interface if I am correct.
 

Latest posts

Top