New Naim NDX

The white paper is itself incomplete.

quote:

Originally posted by pcstockton:

quote:

Claiming that the Naim DAC white paper is wrong has always been one of the possible explanations.

... or people's interpretation/understanding of the white paper is incomplete.

Mine certainly is. Plenty in there that goes over my head.

But I do not see how the simple, clear statement that I quoted above (about how the DAC "eliminates jitter caused by S/PDIF") can be open to interpretation.

It either does or it does not. It is either a true statement or a false statement.

Hook

quote:

Originally posted by Peter Dinh:
The white paper is itself incomplete.

Hi Peter -

How so?

Thanks.

Hook

quote:

Hi AMA -

Claiming that the Naim DAC white paper is wrong has always been one of the possible explanations.

As far as I know, you are the first to make this claim.

Hook

Hook, if you read White Paper carefully you may find they never claim nDAC removes the jitter completely.

You are probably the first who did not notice this.

Hi AMA

I think that with your idea of wave-form distortion causing faulty bit-interpretation, you overstep too easily the fact that spdif is a BMC encoded signal. It is not just a string of 0s and 1s in a more or less perfectly formed waveform.

The data is encoded in the phase shifts of the signal. The wave-form doesn't have to be perfect as long as you can detect the phase shifts in the signal, you can decode the data-bits.

I think your theory on waveforms is correct for digital signal processing but not for the stage where the signal has been spdif encoded.

-
aleg

quote:

Hello AMA,

wikipedia states "Jitter is the time variation of a periodic signal in electronics and telecommunications"
What do you mean with "nDAC is not immune to jitter" and "nDAC is doing is it's removing time-based jitter almost completely. Or possibly completely". This contradicts as jitter has always something to do with time

I can put more words in my previous statement: if original bitstream has a perfect waveform (a sequence of equally shaped peaks) but suffers from time variation of peaks (in certain limits) then nDAC will resolve all the bits accurately (by running the matching clock and buffering the data). It's a great step in designs: one can claim that nDAC removes time-related jitter completely (this type of jitter is induced induced by S/PDIF generator clock instability). But timing is not the only source of what is today understood as jitter and that leaves a space for the difference between transports.

Wikipedia says:

"Jitter in technical terms is the deviation in or displacement of some aspect of the pulses in a high-frequency digital signal. As the name suggests, jitter can be thought of as shaky pulses. The deviation can be in terms of amplitude, phase timing, or the width of the signal pulse."

Please, note the words in red.

Anyway, it's not the point how do you call imperfectness of original bitstream recorded on CD: jitter or whatever. The point is that different transports read the data from the same file and then send this data to the output S/PDIF with different quality.

I think Aleg made a very good point regarding biphase mark code.
Normaly you have the data and a clock to retrieve the data and the data is stored as absolute voltage values. If the clock and the data are shifted against each other, than i can understand your problem with distorted waveforms.

But in contrast to this data coding the BMC stores the data in transitions or changes from a positive to a negative voltage. That means if you want a bit flip the waveform must be heavily distorted in such way that there is no polarity change anymore.

quote:

That means if you want a bit flip the waveform must be heavily distorted in such way that there is no polarity change anymore.

If the slope of the next peak is retarded then S/PDIF receiver may misread this bit. It has nothing to do with timing between the peaks or duration of the peak or amplitude of the peak. It's a shape distortion which happens to any waveform (analogue or digital) because of bad power supply or grounding issues or RF noise etc. You may call this type of distortion as "heavily" -- I would not. I believe if you zoom the distorted waveform then a man eye can still discern the peaks. But it may be a tough task for S/PDIF to resolve them.

quote:

Originally posted by AMA:

quote:

That means if you want a bit flip the waveform must be heavily distorted in such way that there is no polarity change anymore.

If the slope of the next peak is retarded then S/PDIF receiver may misread this bit. It has nothing to do with timing between the peaks or duration of the peak or amplitude of the peak. It's a shape distortion which happens to any waveform (analogue or digital) because of bad power supply or grounding issues or RF noise etc. You may call this type of distortion as "heavily" -- I would not. I believe if you zoom the distorted waveform then a man eye can still discern the peaks. But it may be a tough task for S/PDIF to resolve them.

AMA

Please read the links about BMC.

SPDIF receivers are not triggered by slopes of wave-forms, but by polarity changes of the signal. So your slope can be degraded as h***l, as long as there is a polarity change at the right time, the SPDIF receiver can interpret the data-bit in the signal.

-
aleg

Aleg, I've learnt BMC coding long ago. Still I claim that S/PDIF receiver definitely responds to the slope of the waveform. The BMC coding is a smart idea to get away from setting the 0 and 1 based on the voltage and change for the slope analysis instead. But it's still the same story -- if a slope is not pronounced you may flip the bit.

Have a look at the picture down the wikipedia link. In practical case there is no clock sequence and there is no data sequence. In real life there is only Encoded (BMC) sequence which should be decoded in data sequence -- and that's the ultimate goal.
The real peaks are not square shape but saw-shape with prolonged slopes which can take a half of the pulse duration or more.
Now imagine the slope is distorted (for example delayed) -- then S/PDIF receiver may not identify it as an uprise and that will lead to mis-interpretation of the incoming bit.

In other words, you may think of any coding algorithm you want -- it will only work if the waveform of the encoded bitstream is resolvable. If the pulses are not clearly pronounced the receiver will periodically fail to identify the pulse sequence and this will lead to mistakes in decoding the data bits.

There is only one way to eliminate the mistakes in reading the bits -- repeated reading until the checksum is OK. And this method is the only one used throughout the computer industry.

quote:

Originally posted by AMA:

quote:

Hi AMA -

Claiming that the Naim DAC white paper is wrong has always been one of the possible explanations.

As far as I know, you are the first to make this claim.

Hook

Hook, if you read White Paper carefully you may find they never claim nDAC removes the jitter completely.

You are probably the first who did not notice this.

Gee, AMA, that is not the most helpful response you've ever posted.

I have read the white paper multiple times, but it is certainly possible I am missing something. For gosh sakes, I just said that a lot of it goes over my head!

If I really am the first to be this stupid, then I will have no problem admitting to it. This discussion isn't about ego for me. My only goal for participating is to have a better understand how the DAC works (or in this case, doesn't work). After all, this understanding (or lack thereof) will determine how much money I would spend on a transport. So for me, this is not a purely academic exercise.

Anyway, would it be too much trouble for you to refer to the parts of the white paper that led you to your conclusion?

Thanks a lot!

Hook

PS - Please note I did quote the text from the white paper (twice) that led me to the conclusion that all S/PDIF related jitter was removed. In addition, Naim continues to market the DAC as "zero added jitter".

PPS - Also, if you are referring to the jitter that was present during the recording process, and is indistinguishable from the original signal on playback, I am aware of it and please note that I did mention it in previous posts. Thanks again!

quote:

Originally posted by AMA:
Aleg, I've learnt BMC coding long ago. Still I claim that S/PDIF receiver definitely responds to the slope of the waveform.

...

AMA

I think I'll make this my last post on the subject because we are getting way out of the OP subject. But I must admit I like to bite in a subject like a terrier.

I still find it strange that an encoding specifically designed to be phase modulated, should depend on waveform slopes.

So I delved a little deeper and took the datasheet of the Cirrus CS8414 Digital Audio Receiver which decodes digital audio data.

This chip has an on-board RS-422 line receiver to decode digital input signals. The RS-422 uses a differential input Schmitt trigger circuit, setup against ground as a reference level in RCA-connections, to act as a comparator to detect phase changes. The input being checked against ground means, AFAIK, that it will be triggered by the switching of a positive to negative voltage and v.v. lying outside the hysteresis curve (only 50 mV in said line receiver).

How do you see this mechanism influenced by waveform slope of the digital bitstream?

-
aleg

AMA, you are right that you can distort the slopes in such a way that the receiver cannot extract the original bit sequence (look at my first link fig 5b for a signal with a bit lost at cell position 3 to 4 because of a distorted rise and fall time). But i still believe that this is a massive degradation which should not occur in a decent audio system e.g. naim sources. So i doubt this (!) is the reason that different naim sources sound different.

Do you have any real life example that the bitstream is in such a way distorted?

My first post had nothing to do with the above discussion and seems to get lost in this thread, but can someone explain me the benefit of the audio chain at manchester hdx->ndx->dac versus hdx->dac regarding sound quality? what is the added value of the ndx?

quote:

If I really am the first to be this stupid, then I will have no problem admitting to it. This discussion isn't about ego for me.

Hook, cool down. I would like to be your friend, not a "teacher" or a "teaser"
I'm not "know-everything" and I'm not a digital engineer at all. I can be easily mistaken.
What drives me at the moment is a sheer logic.
I would love if someone finds a week point in my logic and I will learn through this.
What I liked with Andy is that he always used grounded scientific-based objections and it helped me to understand what was wrong in my line of thoughts.

quote:

In addition, Naim continues to market the DAC as "zero added jitter".

I agree. Andy agrees. Everyone agrees. Yes, nDAC does not add jitter. How does it relate to the problem of removing jitter from the input bitstream? To me -- these are absolutely two different agendas.

quote:

Originally posted by jerryct:
My first post had nothing to do with the above discussion and seems to get lost in this thread, but can someone explain me the benefit of the audio chain at manchester hdx->ndx->dac versus hdx->dac regarding sound quality? what is the added value of the ndx?

Jerry
Was is presented as such, i.e. having an advantage in sound quality?

I would imagine it shows the possibility of the HDX to be used as a server, besides being a local player. Furthermore the NDX being a streamer, needs to have a server. And no better servers than Naim servers.

HDX into DAC is a purely local player setup. An added NDX could be in a different room.

So I would say its more about features and possible setups.

-
aleg

quote:

Do you have any real life example that the bitstream is in such a way distorted?

Yes, I hear it each and every time I change transport into my nDAC

quote:

Originally posted by AMA:

quote:

Do you have any real life example that the bitstream is in such a way distorted?

Yes, I hear it each and every time I change transport into my nDAC

Mmh, but this does not prove your theory. Maybe its another influence and the audio signal shows otherwise differences!?

OK, I can use a proof from contradiction.
If the bitstream waveform is OK then S/PDIF transmission should be flawless -- I don't see any other reason which can force the bit flips -- and all the transports will sound the same through re-clocking DAC (which is not the case in my system). I assume that once the bitstream is properly copied to the DAC's buffer it looses any connection to original bitstream timing/waveform and runs the show from the scratch. I also assume that a transport is good enough to avoid reading errors from the data media.

quote:

Originally posted by AMA:...
Hook, cool down...

Hi AMA -

Oh gosh, am not angry at all!

Have always believed that we should challenge the post, and not the poster. I did not agree with your initial assertion that "serious trials" had "proven" AS's position to be "wrong." Simple as that. Nothing personal. I think you are a good, smart guy, and I very much appreciate that you (and Aleg and JerryCT) are willing to take the time to help explore this complex topic (especially since others like Jan-Erik think it is a total waste of time).

So AMA, your last comment was "... nDAC does not add jitter. How does it relate to the problem of removing jitter from the input bitstream? To me -- these are absolutely two different agendas."

I agree - they are.

As far as removing jitter goes, and until someone can quote Naim documentation to the contrary, I will continue to believe that Naim's official position is that all jitter is removed from the incoming bit stream. I simply do not understand how this passage from the white paper can be otherwise interpreted:

"...How to overcome the problem of S/PDIF induced jitter

In the Naim DAC the master clock is not recovered from the S/PDIF signal as usual. Instead the audio data is read from S/PDIF, stored in solid-state memory and then clocked back out to the DAC chips using a fixed-frequency local master clock. This eliminates jitter caused by S/PDIF."

Naim does not say here that they merely do not add S/PDIF-related jitter. They clearly say they "elimininate" it! If there are other parts of the white paper that contradict this statement, or, as Peter Dinh said, if the white paper is incomplete, then I am all ears. I tried and cannot find anything like that. No clue if Peter plans to return and add to his brief statement.

Likewise, AS could not have been more clear in his interpretation of the white paper:

"...With the Naim DAC, the designers have removed the problems associated with jitter as the data is completely reclocked by placing this data in an intermediate RAM buffer and then read out using another clock that is not coupled to the incoming clock. This has the effect of removing any jitter effected clock (i.e. noisy) from the source component and replacing it with the controlled clock within the DAC. As I've said many times before this should make the Naim DAC transport agnostic. ..."

And as far as I can tell, the "zero-added jitter" phrase was simply added by Naim marketing (or legal?) to cover the fact that nobody can eliminate the jitter was generated during the recording process. For any and all transports, jitter added during recording will be indistinguishable from the original signal on playback.

So, unless I am still being dense, your position is that:

1) an in-spec S/PDIF receiver is capable of "fooled" by transmission errors to the extent that it can influence sound quality, and

2) the Naim DAC does not remove *all* S/PDIF-related jitter, thus allowing timing errors to influence sound quality.

Have already said that Naim seems to agree with 1), but only in the case of "cheap digital players...which may suffer RF noise". That's why I suggested earlier that perhaps there is a threshold of quality, above which all transports are indistinguishable. The only question is where that threshold is. My guess (hope?) is that you do not need an HDX or CDX2 to get there. In the case of 2), I will continue to think otherwise until you or Peter Dinh or somebody else can explain how the white paper contradicts itself, is incomplete, or can be otherwise interpreted. After all, it is the only official source of Naim official comment on this topic (since nobody from HQ has commented).

I really do have nothing else to add, so I will leave the last words on this topic to you and others. See you on another thread, bro!

Hook

There is still noise and Jitter from the source unrelated to the spdif transfer to account for differences. What comes out the other side of correction may look like great squares and jitter free of source components but they would have been sampled into the mix. Naim warns of noise. This is one reason why. How they do it seems to get closer to what the original signal was, even on poor sources (sometimes remarkably so)than others I've tried but for me, differences still exist.

quote:

Originally posted by ghook2020:
... I will continue to believe that Naim's official position is that all jitter is removed from the incoming bit stream. ...

Hello Hook,
in May 2010 there was a statement from Richard Dane "Just to throw something into the discussion here. In an email conversation with one Naim's digital engineers, he confirmed that the DAC does remove "all" (his parenthesis) spdif related jitter, and that this can easily be measured. However, he went on to say that nobody has yet figured out a way to avoid jitter completely..."

So this is a strong statement regarding "spdif related jitter" - but one can debate what the parenthesis means.

But you should be careful with the wording "all jitter" because you can not eliminate all jitter. That is for example the jitter that is introduced in the recording studio or at the DA-Conversion.

quote:

Originally posted by AMA:
If the bitstream waveform is OK then S/PDIF transmission should be flawless -- I don't see any other reason which can force the bit flips

You are strongly focusing on bit flips which i think are unlikely. Most configurations of the DAC seem to be base on an electrical spdif connection which may introduce electrical noise. But this noise need not manifest in bit flips.

Instead it can attack other components in the DAC - for example the analog stage. And regarding this problem the white paper states "Together these measures significantly reduce the digtal RF noise which could affect the analogue stage." (they take the wording reduce not eliminate).

In this case you also have different sounding transport and the bitstream wave form is ok and spdif transmission is flawless but you cannot deduce that bit flips are the root cause.

17 pages full of talk about the NDX and only a very few heard a pre production NDX and no one heard a production untit.

I will wait and listen to it with a "normal" UPnP server since I will surely not use it with a HDX as a server and even the UnitiServe seems to be quite expansive as a server or does a Linn DS needs a MajikServe, AkurateServe or KlimaxServe in order to sound 100 percent?

quote:

Most configurations of the DAC seem to be base on an electrical spdif connection which may introduce electrical noise.

Not at all. I did my tests with different transports through tosslink where RF and grounding issues are eliminated. The transports still sounded differently.