Why is the nDAC so cheap?
Posted by: Andy S on 04 May 2010
Serious question.
Have Naim scored an own goal? Using a cheap PC and optical to DAC on it's own is such a massive boost over my old CDS1 it just isn't funny and a mate is selling his CDS3 head end as the PC/DAC/XPS is as close as you could get to a CDS3. Not only that, I can connect up a number of sources and get benefit - the TV sounds SO much better through it.
Don't get me wrong, I'm not complaining since I've just bought one (the demo only lasted 5 minutes in all honesty - the distance was that big), just curious...
Have Naim scored an own goal? Using a cheap PC and optical to DAC on it's own is such a massive boost over my old CDS1 it just isn't funny and a mate is selling his CDS3 head end as the PC/DAC/XPS is as close as you could get to a CDS3. Not only that, I can connect up a number of sources and get benefit - the TV sounds SO much better through it.
Don't get me wrong, I'm not complaining since I've just bought one (the demo only lasted 5 minutes in all honesty - the distance was that big), just curious...
LOL... I'm not trying to win anything (but if I was, it would be a 555quote:Originally posted by gav111n:
OK, OK, Andy, you win 'DAC'.
Your prize is a CDS3!
It should make a beautiful plinth for your laptop.
Gav.
)!! Just trying to understand any mechanism that would cause streamed audio to sound any better or worse than a transport... People are hearing differences - I just can't put it right in my own mind why.As to laptop - I don't use one to stream! I have a htpc in a silverstone case under my TV which does both audio and video streaming - all controlled by a remote and a sexy on screen UI
Nope. SPDIF is bit perfect in transmission. If it isn't, the DAC can't sync to the incoming signal as you'll lose framing bits.quote:Originally posted by DanBa:
But if the above SPDIF transmitter-jittered bit stream is affected / jittered by other noise sources, than the SPDIF receiver cannot perfectly decode it, and the read and stored data is more or less perfect.
This says you get jitter.quote:“However, the situation is still far from ideal. Incoming SPDIF data link is affected by interface jitter in all its components: its transitions timing is perturbed by both transmitter, line induced and interfering noise jitter. The transitions that should be used to reconstruct the data link bit clock are not precisely timed and irremediably modified in an unknown way during transmission process.”
This says you get jitterquote:(“Line induced jitter is instead caused by the transmission medium. Any connection link has a limited bandwidth, that makes transitions slower than ideal and this causes waveform deformations that can be easily studied with an oscilloscope (eye pattern).”
This says you get jitter.quote:“Interfering-noise induced jitter is another consequence of the limited slope of the transitions. If we inject a small (compared to the signal) amount of noise in the SPDIF channel, this will add to the signal, modifying its instantaneous value. If the noise is low, ad as such is not be able to transform a 0 into a 1, there are no transmission errors, but the signal level will be altered also during the transitions, so that the 0 crossing time will be affected”)
Oh - cool, but what does this have to do with the discussion about the nDAC?quote:"While the Bridge has a Lens built into it (as does the PWT) there's plenty difference between the outboard standalone Lens and the built in one. For one thing, the standalone Lens has a very complex receiver called the Symbolic Logic Receiver that takes the S/PDIF signals coming into it and removes the data and throws away the clocks. Neither built in Lens has this chore nor the ability and hardware to pull it off. This is a very big piece of engineering in the standalone Lens and took nearly three years of work (at various times in the last decade) to figure it out. First conceived by myself and then implemented by Bob Stadtherr - that early version never saw the light of day. Our Romanian engineering team, led by our good friend Nucu, has designed a modern version of this fascinating circuit which, frankly, is the heart of the outboard Lens and what makes it so special.
The SLR does not rely on edge triggering to decode the PCM signals. Instead, it takes a series of snapshots and figures out what the pattern is of the PCM code based on a set of stored symbols and then assembles these symbols into a meaningful data train. This completely eliminates clocks and jitter before it even goes into the Lens.”
Don't agree with this.quote:Probably well-formed SPDIF PCM signals transmitted by a high-end CD player are more robust against the line induced jitter and and the Interfering-noise induced jitter.
I'll say it once more (it must be the 1000th time I've said it on this thread).
- Transports are bit perfect 99.9% of the time
- SPDIF is a bit perfect transmission medium
- Transports will have more or less jitter depending on their design
- SPDIF will add varying amounts of jitter depending on the cable characteristics
- The reclocking of the nDAC removes all jitter from the transport and SPDIF cable
- Jitter is not the reason people hear differences with the nDAC (IMHO of course )
quote:Originally posted by DarrellK:quote:Originally posted by fatcat:quote:Originally posted by Andy S:Wot he said....quote:Originally posted by DarrellK:
Hi Fatcat,
My (very limited) understanding is however it is introduced to the system (motor, power supply, whatever) jitter manifests itself only as timing errors in the digital bitstream. What other "noise" can there be in the digital domain, apart from making a "1" a "0" or vice-versa? (and if this happened to any extent, you'd likely get no music at all.)
The DAC reclocks the bitstream and so removes the jitter introduced between the reading of the disk and it's arrival in the DAC buffer, however it was caused - the DAC can't "know" how the jitter was introduced, still less care.
Darrell
Definatley, Wot he said
Manifest : To show or demonstrate plainly; reveal:
Jitter reveals the presence of noise.
Wot I really said:
"jitter manifests itself only as timing errors..."
In other words (taking your definition of "manifest"): timing errors (in the bitstream) reveal the presence of jitter.
I suppose it would be more accurate if I had said: "jitter *causes* (only) timing errors in the bitstream presented to the DAC."
Anyway, semantics aside, If I can be so bold as to sum up the thread so far:
Darrell
Jitter doesn’t manifest itself. Jitter is a manifestation of noise, nothing to do with semantics.
If digital data is passed though a circuit that is subjected to noise, the waveform will contain timing errors. Jitter is simply a name given to these timing errors. The greater the noise the greater the jitter. Noise is the phenomenon, timing error in the waveform (jitter) is the observable consequences of the noise.
Similar to a flagpole in the wind, the wind is the phenomenon, the bending of the flagpole is the observable consequences of the wind.
The noise, hence, timing errors (jitter) is not significant in the transmission of the data, as long as the errors are kept within reason.
What is significant is the presence of noise in the circuit.
The clock timing error, also called jitter is a different matter.
The reason the nDAC is expensive and so good is because Naim have put Pixies in each one to sprinkle Pixie dust on each bit as it goes through....quote:Originally posted by DarrellK:
Agreed. But there are some on here who still seem to believe that jitter does more than introduce timing errors in the bitstream ("different types of jitter", etc)
Actually, this explains why it sounds different with different sources - the Pixies look at the source and decide to nobble the bits of lesser sources as they come into the DAC. Simples
Oh dear, that's going to get you into troublequote:Originally posted by Andy S:The reason the nDAC is expensive and so good is because Naim have put Pixies in each one to sprinkle Pixie dust on each bit as it goes through....quote:Originally posted by DarrellK:
Agreed. But there are some on here who still seem to believe that jitter does more than introduce timing errors in the bitstream ("different types of jitter", etc)
Actually, this explains why it sounds different with different sources - the Pixies look at the source and decide to nobble the bits of lesser sources as they come into the DAC. Simples
quote:Originally posted by Andy S:I think you might have been better saying it as: "noise in the transport causes jitter (and only jitter - nothing else) in the bitstream presented to the DAC"quote:Originally posted by DarrellK:
I suppose it would be more accurate if I had said: "jitter *causes* (only) timing errors in the bitstream presented to the DAC."
Andy
I’ll try to make this even simpler for you understand.
As we agree, "noise in the transport causes jitter (and only jitter - nothing else) in the bitstream presented to the DAC".
So, we have a circuit that contains
1. NOISE
2. A Bitstream that contains jitter. (and as you say noise due to timing errors)
TWO TYPES OF NOISE, although one derived from the other.
Lets say we have a cheap DVD player transport that produces lots of noise. This noise produces lots of jitter in the bitstream, but not enough for to cause loss of data at the DAC. The data is transferred bit perfect, as you assure us will happen.
However, the fact remains, the transport produces a lot of noise. This noise will be transferred (although not by bitstream) into the DAC.
On the other hand a transport that produces very little noise, transfers very little noise.
The reason USB sticks sound good, but not the best, is the fact the flashing LED produces a large amount of noise. I’ve built enough guitar fuzz boxes to know the LED is major factor in producing distortion. I keep meaning to take a stick to pieces and see if it works with the LED removed.
quote:Originally posted by Andy S:How?quote:Originally posted by fatcat:
This noise will be transferred (although not by bitstream) into the DAC.
Down the copper wire and tracks that connect the bits and bobs together.
quote:Originally posted by fatcat:quote:Originally posted by Andy S:Nope, they are one and the same thing. The only way noise gets transmitted to the DAC (especially if using optical) is in timing errors. It is impossible for the DAC to separate them out to jitter due to noise in the power supply, jitter due to cable etc... and then only get rid of certain elements of jitter. The nDAC claims to eliminate jitter at the SPDIF interface. If it does this, it will get rid of all noise related jitter from the transport.quote:Originally posted by fatcat:
The clock timing error, also called jitter is a different matter.
No need to separate anything, the clock timing is not carried with the data in a S/PDIF interface. It’s already separate. The S/PDIF interface causes jitter in the clock timing, read the white paper. As you know Naim only claim to eliminate jitter caused by the S/PDIF. Logically this means data jitter (Transport generated) is not removed.
I respectfully suggest you go and read up how all of this works. Your understanding of how the system works doesn't match with reality.quote:Originally posted by fatcat:
No need to separate anything, the clock timing is not carried with the data in a S/PDIF interface. It’s already separate. The S/PDIF interface causes jitter in the clock timing, read the white paper. As you know Naim only claim to eliminate jitter caused by the S/PDIF. Logically this means data jitter (Transport generated) is not removed.
Odd as it might seem, this is the first thread I read on the forum. I was drawn in by the thread title, being a person brand new to NAIM (NAIM ownership that is) and the nDAC. I’ve very much enjoyed the technical debate, and it’s sent me off in many a direction in my attempt to learn more about distributed audio.
I took my leap recently after a great demo of the nDAC. For me, the difference maker was the way in which it transformed my inexpensive MP3 player (playing lossless file format) into a wonderful sounding source. My demo of the product included extensive listening of the CD5xs via the nDAC which sounded awesome to me (and superior, as I would expect, to the MP3 player). However, it was the performance of the MP3 player that convinced me that everything I was going to throw at the nDAC was going to produce a result I could absolutely live with (MP3, Computer/Music Server, and CD). I assumed that my future transport of choice would be a very inexpensive one which would again be transformed into a pleasing (to me of course) source by the nDAC. So, considering I still haven’t purchased my new transport yet, I’ve very much been rooting for Andy as I’ve read through this!
But honestly, what an amazing product. I couldn’t be happier thus far. It’s not cheap, but I believe it’s a great value. And interestingly, might be a product that appeals to first time and budget focused customers, as well as the veteran ranks.
Regards,
Tim
I took my leap recently after a great demo of the nDAC. For me, the difference maker was the way in which it transformed my inexpensive MP3 player (playing lossless file format) into a wonderful sounding source. My demo of the product included extensive listening of the CD5xs via the nDAC which sounded awesome to me (and superior, as I would expect, to the MP3 player). However, it was the performance of the MP3 player that convinced me that everything I was going to throw at the nDAC was going to produce a result I could absolutely live with (MP3, Computer/Music Server, and CD). I assumed that my future transport of choice would be a very inexpensive one which would again be transformed into a pleasing (to me of course) source by the nDAC. So, considering I still haven’t purchased my new transport yet, I’ve very much been rooting for Andy as I’ve read through this!
But honestly, what an amazing product. I couldn’t be happier thus far. It’s not cheap, but I believe it’s a great value. And interestingly, might be a product that appeals to first time and budget focused customers, as well as the veteran ranks.
Regards,
Tim