S/PDIFF decoder in Naim DAC

All you answers are here

http://www.naim-audio.com/down...e_Paper_Aug_2009.pdf

I have seen this paper and they did a lot towards smart S/PDIF decoding, particularly, use 10 various clocks to match the S/PDIF master clock instead of PLL.
It is still not clear how do they recover words and bits once the master clock is recovered which is another source of digital errors.

Anyway I can put it in simple way -- do they negate the use of I2S due to advanced S/PDIF decoding?
Without this new DAC will hardly approach the quality of CDS3 or CD555 or Linn Klimax DS or even Slim Devices Transporter.
I actually need one hour audition of this DAC in my home system to get an answer but this DAC is still not on sales

They've adressed these issues as comprehensively as I've seen and the ladder 1704k is inherently jitter resistant unlike sigma/delta types but as you say, proof will be in the audition. I've heard a few DSP, large buffer reclockers that weren't special so a listen is what matters. Of course, their working frequencies(lower) and filters were quite different. At least the audition reports have been very encouraging. Also remember that the better the stream, the less important the jitter handling, however unique clock(decode) frequencies and benign filtering may set it apart regardless of source. None of this matters without good engineering but I'm sure we all assume that to be fundamentally sound from Naim.

AMA,

The White Paper shows the S/PDIF signal entering the SHARC DSP. I had a quick look at one of the SHARC datasheets and it shows an on board S/PDIF interface, but one that can take it's refrence clock from a variety of sources. Without knowing exactly which SHARC Naim use it's impossible to speculate an further. With regard to I2S, the actual DAC chips need the incoming data in this format, so I don't understand your point about negating the use of I2S? Ultimately whatever technique is used to capture and transform the data it must end up as I2S eventually.

I think the main audible differences for Naim DAC will result from the custom high precision digital filters implemented in the DSP, coupled with the care taken in the I2V, analogue filtering and buffering stages.

I find all the electronics stuff interesting as an academic debate, but like you I just want to get my hands on one and see how it sounds in my room.

quote:

With regard to I2S, the actual DAC chips need the incoming data in this format, so I don't understand your point about negating the use of I2S? Ultimately whatever technique is used to capture and transform the data it must end up as I2S eventually.

Dave,

We are talking about different elements.

I mean I2S between transport and EXTERNAL DAC (through the cable between boxes).
We all know that I2S is a simple protocol which avails the bit-perfect and time-perfect data transmission and makes no differences between the transports connected to external DAC (unfortunately I2S does not have connection standards).
If you link transports to DAC through S/PDIF and DAC is not smart enough to recover the bit-perfect and time-perfect data then different transports will sound differently. Of course, the DAC contains it's own internal I2S interface which transmits the data AFTER S/PDIF decoding, buffering and re-clocking to the BB 1704 chip. But if S/PDIF decoding was poor the further circuits will not improve the data.

As far as I know recovering of master clock is the main point for jitter rejection but not the ultimate cure -- the I2S needs words and bits to be resolved accurately that's why the I2S transmits word clock and bit clock separately from master clock. One can find interesting discussion of these issues on PS Audio forums where they claim they FAILED to achieve I2S quality through S/PDIF and finally implemented external I2S connection between PWT (transport) and PWD (DAC) through HDMI I2S cable and this is -- as they claim -- substantially superior to S/PDIF interface despite the efforts they spent to elaborate very intelligent S/PDIF decoding technology.

Unlike "Digital source (ex.g. CD5XS) --> S/PDIF --> Naim DAC" concept the CDS3, CD555, Linn DS, Transporter -- all have "Transport-->I2S-->DAC" solution which implements simple and cheap and 100% perfect data transmission. Naim always were reluctant to deal with intrinsically ill-designed S/PDIF interface and prefer single-box solution based on I2S. The Supernait and DAC is the first Naim experience in this area which comes on sales as the response to the market trends. The Supernait DAC didn't impress me at all though the amp is very good (I would say deserves better DAC) but Naim DAC is much more sophisticated piece of engineering.
I still leave some hopes that if S/PDIF source does not have a tremendous jitter one can think of a smart procedure which can recover all bits and timings perfectly or at least in-audible from I2S connection. Then I can use my beloved Transporter which is a very low jitter S/PDIF optical source to feed Naim DAC and it can compete with PS Audio PWD I2S or Weiss DAC Firewire in terms of sound clarity (leaving the classic Naim audio virtues aside of this particular test).
BTW I tried HDX and after 5 minutes I understood that I'm not yet ready to part with Sean Adams ingenious products.

[QUOTE]Originally posted by AMA:
We all know that I2S is a simple protocol which avails the bit-perfect and time-perfect data transmission and makes no differences between the transports connected to external DAC (unfortunately I2S does not have connection standards).

AMA

Make that everyone but me (and maybe a few others)

Bob

@ AMA

Let us just wait until we can hear how the Naim DAC sounds - everything else is unimportant. I am absolutely sure that Naim found a good way to reduce jitter to a minimum when sudenly coming up with a separate DAC. And DACs are not only about I2S or S/PDIF... The choice of the DAC chip is very important and those "old" multi bit converters such as the BB selected 1704 K are far better resolving than the newer delta sigma converters. Than there is the digital filter, the clock and probably most important of all the analog output stage. I am sure that Naim did a 100% job regarding all parts of the DAC. The only thing I do miss is an asyncronous USB input
The I2S connection is not bad at all, but there are only a very few devices outputting I2S and S/PDIF is widespread and can be considered the standard in home hifi. In the world of recording studios probably AES/EBU is the standard.

quote:

AMA

Make that everyone but me (and maybe a few others) Roll Eyes

Bob

Bob, you are right.

I have to re-arrange my previous statement -- I2S protocol accurately conducts the
data from transport including the transport jitter (!!!) to the DAC without adding more jitter into it.
The key idea of this statement is that I2S does not add more jitter to the original data stream.
Of course, intrinsic transport jitter will penetrate to DAC through I2S and this will make a difference between the transports -- that's exactly what we hear.

At the same time I would suggest that if transport clock is low jitter (say < 300 ps) there will be no audible difference whatever the nature and design of transport is. Not sure about the threshold though. There is a simple mathematical foundation of this figure for 16/44.1 (for hi-res the jitter should be further less to become inaudible). But as far as I know in general case this is not an issue of one figure as detrimental jitter impact is seriously dependent on it's spectrum.

Am I am on the right forum here? This is the Naim Audio Forum isn't it or am I lost somewhere....?

Jim

This it the nerdy electronics folk forum, you must be in the wrong place Jim, I feel right at home

quote:

The only thing I do miss is an asyncronous USB input

John,

USB input implementation in all DACs I have tested in the past was DISASTER as they all used to link the ground of USB source (PC) with gentle ground of DAC's audio circuitry and transmit a huge PC noise through this chain. The noise starts penetrating to all preamp inputs and you hear it even when listening for non-USB preamp inputs.
The best (and cheapest) way to decouple PC from DAC and rest of Naim chain is to connect them with Tosslink.
I use M-Audio Transit (100 K$) and it's not the only choice on the market.

In fact Naim could built-in the similar device in their new DAC but this would challenge them in designing converter and arranging isolated ground loop at a much higher cost than available stock solutions.
I will not be surprised if Naim follows up the market trends and one day includes this option in their Naim DAC2 at another 500 K$.

I'm using a dedicated audio streamer for high quality replay and only use PC/USB/Tosslink/DAC to watch movies.

[QUOTE]Originally posted by AMA:
I have to re-arrange my previous statement -- I2S protocol accurately conducts the
data from transport including the transport jitter (!!!) to the DAC without adding more jitter into it.

AMA

sounds more likely

Cheers

Bob

quote:

Originally posted by AMA:

I use M-Audio Transit (100 K$)

100K????? I bought mine for $69 USD.

quote:

Originally posted by AMA:

quote:

AMA

Make that everyone but me (and maybe a few others) Roll Eyes

Bob

Bob, you are right.

I have to re-arrange my previous statement -- I2S protocol accurately conducts the
data from transport including the transport jitter (!!!) to the DAC without adding more jitter into it.
The key idea of this statement is that I2S does not add more jitter to the original data stream.
Of course, intrinsic transport jitter will penetrate to DAC through I2S and this will make a difference between the transports -- that's exactly what we hear.

At the same time I would suggest that if transport clock is low jitter (say < 300 ps) there will be no audible difference whatever the nature and design of transport is. Not sure about the threshold though. There is a simple mathematical foundation of this figure for 16/44.1 (for hi-res the jitter should be further less to become inaudible). But as far as I know in general case this is not an issue of one figure as detrimental jitter impact is seriously dependent on it's spectrum.

Before I make my comment here ... I should point out I'm not an engineer (well not qualified) just an interested person who reads a lot.

While some manufacturers do agree with this statement (that i2s is best) there are others who say this is a flawed thought and that unless the cables are exact, the variations between the clock line and data lines when using i2s externally (remember i2s is designed for linking chips over a few CM on a circuit board) can actually degrade the audio worse than any SPDIF link, especially as there is no way to resync the data to a new clock.

Eloise

Eloise,

This is down to implementation -- not to the concept.
I2S protocol is a native format for data supply into all (!!!) DACs
and THEORETICALLY is the best way to transmit the digital time-coded data between the boxes.

quote:

100K????? Eek I bought mine for $69 USD. Winker

I'm OK to correct 100K$ for 100$ but I'm still upset with a 31 $ extra I paid to my local M-Audio dealer
Unless you live next door to M-Audio factory and get a magic discount on their remarkable products

quote:

Originally posted by AMA:
Eloise,

This is down to implementation -- not to the concept.
I2S protocol is a native format for data supply into all (!!!) DACs
and THEORETICALLY is the best way to transmit the digital time-coded data between the boxes.

THEORETICALLY it is the best way to transmit data between an SPDIF reciever or internal transport and the input of a DAC chip BUT ONLY WITHIN A SINGLE CHASSIS. It is not the best way to transmit data between boxes UNLESS you create your own error checking and recovery system. The i2s system was designed (as I stated before) for transfer over short distances with identical, parallel signal paths. It will work over a longer cable but working and being ideal is not the same thing.

I'm not just making this up, it has been explicitly stated by some manufacturers and implied by others. Naim, by the fact that they have not implemented i2s transfer from the 5XS and CDX2-2 when used as transports, have implied to my mind that i2s IS NOT the best method.

Eloise

Eloise,

I have a feeling that once the input digital stream is not dreadfully polluted and S/PDIF decoding is properly implemented than all bits can be accurately recovered and buffered making the I2S vs S/PDIF contest pointless
And this is possibly the way Naim goes.

I still have a technical puzzle on what exactly may spoil in I2S inter-box communication (let it be 1 m for example) in order to make some engineers think the I2S is CONCEPTUALLY inferior to S/PDIF
I'm open minded -- just curious
I don't worship PS Audio but I really appreciate their openness in discussing the modern architecture.
The story on I2S vs S/PDIF is very convincing...

All I can really say is that I've read several people cautioning against thinking of i2s as a universal panacea.

One example is dCS who have this to say on their website...
I2S Vs. SPDIF
I2S is the data format produced by CD mechanisms, it consists of 3 wires: a Frame (or Word Clock), a Bit Clock and a data line carrying a stereo pair of data streams. I2S is intended for connections between chips a few centimeters apart, not between separate boxes. The 3 cables MUST be exactly the same length, otherwise the data clocked into the DAC may be corrupted due to cable delays.

I2S is used in this way to avoid the need for a Phase-Locked-Loop (PLL) in the DAC, in the belief that this will reduce the level of jitter. In reality, the clock from the CD mechanism is typically very jittery, but there is no PLL in the system to filter out this jitter!

SPDIF is well established and gives excellent results in a well-designed system.

The PS Audio combo is unarguably a great system ... but then I've also seen comments of people using the PWT(ransport) with alternative DACs to the PWD (similar price ones) and getting better results and this was via AE rather than i2s.

Personally I am going to trust in the designers of the products and not second guess them. For example Naim have presumably considered lots of options for interconnectivity with the new DAC and have decided against i2s - while also recognising that the PWT / PWD combo does seam to work better when using i2s - and I will assume that is for a reason...

Eloise

Eloise,

Now I see the point.
I agree that dCS takes a special care on smart S/PDIF data
recovering and possibly are the best in this (they don't use stock solutions).
In above excerpt they actually refer to the simple fact that PLL treatment which follows
the S/PDIF input will reject jitter no matter where this jitter emanates from:
either transport's clock or transport's S/PDIF generator or DAC's S/PDI receiver or all of them.
While I2S takes no effort to reject the jitter from transport's clock and focus on flawless transmission of transport's data ruling out the transport's S/PDIF generator jitter and DAC's S/PDIF receiver jitter.
This is very true.
This only means that I2S transmission assumes that transport's clock should be slaved with DAC's super-fine clock and the I2S cable is to resist RF. PWT/PWD is the high quality implementation of this concept (but surprisingly slaving in backward direction).

Eloise, I put only theoretical considerations in my posts. I have not yet listened for PWT/PWD.
PS Audio put a lot of efforts in elaborating a smart S/PDIF decoder using the proprietary solutions and still claim
that PWT/PWD provides AUDIBLY better clarity. This could be a commercial -- who knows?
dCS produce one of the best digital sources through the S/PDIF input.
I do believe if a transport with S/PDIF output is low jitter (like Slim Devices Transporter) then a smart S/PIDF receiver will manage the bit-stream and make no difference with I2S transmission. If it happens the Naim DAC will be superior to Naim's best CDPs (when running through the same PS). Let's hope for the best while waiting for the Naim DAC advent!

AMA,

Flat earth rules.

-patrick