Is music streamed to NDX passed to Naim de-jitter buffers?

Posted by: Razor on 08 December 2010

The NDX white paper is in parts copied and pasted from the HDX and nDAC white papers and has not been properly reviewed as one or two items copied have not been changed for the NDX. For example, one section says "well below the noise floor of the DAC chips" but there is only one DAC chip in the NDX.

An early paragraph in the paper says "So the ripping engine developed as part of Naim’s HDX hard disk player became the first building block of the NDX." But the NDX does not do ripping!

Some of the Analogue Output Filter section is copied word-for-word from the HDX white paper but with just a change of op-amp type; this is puzzling as the same words are used to justify the choice of different op-amps.

Because of these weaknesses I find it hard to draw definitive conclusions from this paper. However, it is clear from the NDX's white paper that data arriving over SP/DIF is passed to the NDX's de-jitter buffers:

"When the NDX is playing audio via S/PDIF, the source of the S/PDIF signal is the master and the NDX’s master clock must, on average, match the frequency of the source clock. ..."

However, it is not explicity stated that data arriving through the NDX's streaming module goes through the same de-jittering. Now it may well be the case that there is less jitter generated by the streamer than by SP/DIF, but even so it would make sense to use the de-jittering as for SPDIF. It is true that the schematic suggests that this is the case, but schematics are of necessity approximations.

Can someone please tell me whether or not data streamed to the NDX, as distinct from passed through SP/DIF, goes through the de-jittering process just like SP/DIF data does?
Posted on: 08 December 2010 by james n
quote:
An early paragraph in the paper says "So the ripping engine developed as part of Naim’s HDX hard disk player became the first building block of the NDX." But the NDX does not do ripping!


Quite right, but put it into the correct context and its clear that as part of the project brief, the ripping engine designed for the HDX was used as the starting point. Naim think they have this right so that's the 'source' taken care of.

Given that the output from the Streamer module passes through the isolation block and into the DSP (as does the S/PDIF data) then i'd put money on the data being treated the same way via the ram buffer.

James
Posted on: 08 December 2010 by james n
Actually another interesting note is raised in the white paper which agrees with what quite a few people have found -

Even lossless compression may not reproduce audio with equivalent quality to the uncompressed original as the processing required to uncompress the data increases the computational load. This raises the power supply noise floor, which detracts from the sound quality

James
Posted on: 08 December 2010 by likesmusic
Surely the data that is streamed to the NDX over a network is streamed in network packets; there is no clock signal embedded in these packets, so there can be no inherent jitter, so there is nothing to 'de-jitter'.
Posted on: 08 December 2010 by Razor
To likesmusic. True there is no clock signal embedded in the packets, but there has to be a clock, presumably in the streamer module, to sequence reading the data out of the buffers in the streamer and sending it on ultimately to the DAC chip. The clock that does this will have jitter.
Posted on: 08 December 2010 by likesmusic
The packets are sent as and when needed, and will be buffered in the NDX, rather as a printer buffers a document. There is, for sure, a clock in whatever is sending the packets, and it may or may not be a good one, but since the clock signal itself is not sent, then it's quality is immaterial. The network packets will go into a buffer, and the NDX can clock these out absolutely under it's own control, so whatever jitter is introduced is entirely down to the quality of the clock in the NDX. This is a clear advantage of the network paradigm.
Posted on: 08 December 2010 by Razor
quote:
The network packets will go into a buffer, and the NDX can clock these out absolutely under it's own control, so whatever jitter is introduced is entirely down to the quality of the clock in the NDX.


Thanks likesmusic, but are the buffer and clock that you refer to not those that form the Naim de-jittering mechanism? It seems to me you have described the same process as SP/DIF data goes through and so you now appear to be saying that streamed data is treated like SP/DIF data. Confused
Posted on: 08 December 2010 by likesmusic
Well .. as I understand it .. (and I may not) .. the essence of the NAIM DAC is really the other way around, in that S/PDIF data is treated like streamed data. The S/PDIF input is read into a buffer, and the 'correct' clock frequency is deduced, and then the corresponding, completely independent, clock in the DAC is used to clock it out. So effectively the clock entangled with the S/PDIF is discarded, so that the DAC is not vulnerable to variations (ie jitter) in it's frequency. So to me the Naim DACs strategy is (kind of) to turn an s/pdif data stream into a buffered, clockless, data stream just like data from the network. Naim aren't claiming there is no jitter in their DAC, their claim is that jitter from the s/pdif source is removed. Their own clock(s) will have some amount of jitter, but this is (one hopes) much less than were they to use the clock extracted from the s/pdif data.