On why the Naim DAC is jitter-immune (longish)
Posted by: bhaagensen on 23 January 2010
... or at least why I think it is.
Due to recent discussion threads, I hope to explain exactly why I personally find it difficult to understand how or why jitter-related issues could be an issue in the context of transports for the Naim DAC and thereby perhaps learn where my understanding is wrong. Its as such not intended for deriving conclusions about the sound-quality. This is all about jitter - some would say sound-quality is not at all about jitter
It gotten a bit long, so I've divided into two parts. The first (hopefully) describes the problem and common solutions. The last part is specific to what Naim are doing. Everything written should of course be quotiented by my limited knowledge - it may be so wrong that its not even wrong. If you want the correct version, see the whitepaper
======================== PART I ========================
Firstly. There are many kinds of jitter, and the significance of any given kind also depends on its frequency spectrum. This is of no importance to the final argument of the following. Moreover jitter, of the kind discussed here, is [u]by definition[/u] only created when converting the signal, analog-to-digital (AD) or the opposite direction (DA).
Considering the simplified (and not really correct, but sufficient for this purpose) chain of audio-data, lets call it a signal S, from source to Storage on a computer based device (including e.g. the HDX where applicable):
-------- / CD ------------> CD-Reader (drive) \
Studio -> Online music --> Network ------------> Storage
-------- \ Other ---------> Interface ---------/
When leaving Studio, S is already jittery from any of the AD-stages of creation. Nothing to do about this, but lets call it J0. Since there are no AD or DA stages in the chain from Studio to Storage, the jitter at the latter in S is still J0.
Let R denote the samplerate, which could be any such as 44.1,48,88,96,... Consider the simplified chain when using a streamer and an external DAC connected via S/PDIF.
Storage -> Network -> Streamer -> S/PDIF Transmitter -> Cable -> S/PDIF Receiver -> DAC Chip
------------------------------ | ------------------- | ------ | --------------------------- |
------------------------------ | ----- Clock A ------ | ------ | ---------- Clock B ---------- |
------------------------------ | ------------------- | ------ | --------------------------- |
Again, from Storage to Streamer there are no AD nor DA stages, hence at Streamer the jitter in S remains J0. The clock colums signify that all components in a column are driven by the same clock to which they must be in perfect sync to avoid jitter. Because the jitter at Streamer is J0, so only consider the chain from Stremaer to the final conversion-stage.
When Streamer sends S to the DAC (S/PDIF Receiver + DAC Chip), it does so using the S/PDIF Transmitter at a rate R provided by the clock A. The DAC Chip performs DA at a rate given by the clock B. Let At be the time between the ticks of A, and Bt the same for B. Does it work?
Consider first the idealised dream-scenario, which entails mainly the following: a) There are perfect clocks such that At=Bt. The frequcy for both is simply R, b) the S/PDIF Transmitter, Cable, and S/PDIF Receiver are 100% jitter-free. c) there is no delay, nor jitter, from the S/PDIF Receiver to the DAC-Chip. Given these assumptions the entire system works by letting B synchronise on the first incoming bit*. The system now clearly does not add any jitter at all. The amount of which at at the DAC-Chip is simply the good old J0.
Obviously, none of the above are real-world realisable. Until now most DAC chip producers have solved this by letting B be derived from A which is encoded in S. This is often refered to as: PLL, reclocking, ASRC, jitter-removal, jitter-elimination etc. Lets simply call it reclocking. Since B is now derived from S and dependent on A, lets call that clock B[A]=f(S) to signify that it depends on the signal S, via some procedure f. Pictorially:
Streamer -> S/PDIF Transmitter -> Cable -> S/PDIF Receiver -> Buffer -> DAC Chip
--------- | ------------------- | ------ | ----------------------------------- |
--------- | ----- Clock A ------ | ------ | ----------- Clock B[A] ------------- |
--------- | ------------------- | ------ | ----------------------------------- |
The Buffer is needed between that S/PDIF Receiver and the DAC Chip in order to do e.g. ASRC.
Now how does this setup relate to the dream-scenario: Ad. b) Here jitter occurs, and this is of the kind often refered to by terms such as: s/dpif generated jitter or transport-jitter. Lets call J1'. The [u]crux of the matter[/u] is that as far as jitter goes, any differences between the e.g. the Transporter and the SB3 is represented in J1'. Ad. a) Now because of J1' influence on S, the reclocking function f can in general never guarantee to obtain exactly the clock A from S. It will leave some remains of J1', which can be called J1. Ad. c) Clearly it does not hold in the theoretical sense cf. the speed of light. However the delay is neglible. Nonetheless because of this, and since the three components driven by B[A] can not be 100% synchronised, jitter does occur here. Lets call this J2. So the system is now real-world working, but at the cost of a total jitter at the DAC Chip of J0+J1+J2.
======================== PART II ========================
Now lets try and aim in on the solution used in the Naim DAC. The jitter J2 is not possible to get rid of as such**. So J1 is the target. J1 ultimately resulted because of the insufficiency of the reclocking-design. Lets backtrack and reconsider the first solution, but loose the assumption a). If it worked, there would be two independent stable clocks so J1 would be eliminated. Leaving jitter at the DAC Chip at the best possible result, wiz J0 + J1.
Unfortunately because of b) it doesn't work since no choice of stable clock B can match the jittery (c.f. b)) incoming signal. If A is too slow bits would be missed, and if its too fast there would be no availble bits from the S/PDIF Transmitter. Now lets combine and refine by adding a buffer as in the second solution and use two clocks in the DAC. One reclocking based B[A] for getting data into the DAC, and and another 100% local crystal oscilliator based B for clocking the signal out of the buffer and the DAC Chip. Pictorially:
Streamer -> S/PDIF Transmitter -> Cable -> S/PDIF Receiver -> Buffer -> DAC Chip
--------- | ------------------- | ------ | --------------- | ------------------ |
--------- | ------ Clock A----- | ------ | - Clock B[A] - | ----- Clock B ----- |
--------- | ------------------- | ------ | --------------- | ------------------ |
If now the average time (over some interval) between the ticks of B[A] was matched by B this would then work. More [u]importantly[u/], it would completely eliminate all jitter J1 since B is 100% local to the circuit clocking data out of the local buffer and driving the DAC Chip. Unfortunately such a fixed single clock B that would match all scenarios does not exist. B would very likely not match the average of the clock B[A]. Hence even the buffer would under- or overrun at some point. A helpful analogy is a waterhose with a tap at each end. Unless both taps (clocks) are set to exactly the same capasity, "holes" will occur, or "pressure" will build up. The buffer may be thought of as a finite volume resorvoir connected to the hose.
But this now hints at the final solution. Rather than fixing B at some predefined tick-rate (frequency), one simply makes available a set of 10 slightly different and cleverly chosen fixed local clocks. One of these will likely be a sufficiently close match to the average tick-rate of B[A] for the buffer not to under- or overrun***
Conclusion. The system therefore operationally works without the assumptions a), b), and c) at the lowest possible jitter level, J0+J2. In particular it is independent of the jitter J1 and J1'. It is essentially nothing but a good practical solution to the "waterhose" problem mentioned above.
Bjørn
=======================================================================================
PS If you made it here, please comment.
PSS I have deliberaty not mentioned bit-errors in transmissions. In the above, they are practically possible only from the stage of the S/PDIF Transmitter and onwards. Statistically the likelihood of such errors is extremely low AFAIK.
PSSS It is true that B may end up running at A+E. This is not jitter.
PSSSS There are too many simplifications in the above to detail them all. But please comment if I've made any that could alter the conclusion.
PSSSSS Since the secondary clock in the Naim DAC is truly independent of the clock in the transport I'd rather not use the term reclocking as it, in my book, implies a functional relationship between the two
PSSSSSS I haven't heard it... yet
* This is not really feasible in general, but its a harmless assumption that becomes voided in a few lines.
** This kind of intrisic jitter obviously varies between devices depending on the quality of those. Naim has a good design and probably very low jitter at this stage.
*** I understand from others that such a match is indeed, for all intents and purposes always found, as can be seen by an indicator-light on the DAC.
Due to recent discussion threads, I hope to explain exactly why I personally find it difficult to understand how or why jitter-related issues could be an issue in the context of transports for the Naim DAC and thereby perhaps learn where my understanding is wrong. Its as such not intended for deriving conclusions about the sound-quality. This is all about jitter - some would say sound-quality is not at all about jitter
It gotten a bit long, so I've divided into two parts. The first (hopefully) describes the problem and common solutions. The last part is specific to what Naim are doing. Everything written should of course be quotiented by my limited knowledge - it may be so wrong that its not even wrong. If you want the correct version, see the whitepaper
======================== PART I ========================
Firstly. There are many kinds of jitter, and the significance of any given kind also depends on its frequency spectrum. This is of no importance to the final argument of the following. Moreover jitter, of the kind discussed here, is [u]by definition[/u] only created when converting the signal, analog-to-digital (AD) or the opposite direction (DA).
Considering the simplified (and not really correct, but sufficient for this purpose) chain of audio-data, lets call it a signal S, from source to Storage on a computer based device (including e.g. the HDX where applicable):
-------- / CD ------------> CD-Reader (drive) \
Studio -> Online music --> Network ------------> Storage
-------- \ Other ---------> Interface ---------/
When leaving Studio, S is already jittery from any of the AD-stages of creation. Nothing to do about this, but lets call it J0. Since there are no AD or DA stages in the chain from Studio to Storage, the jitter at the latter in S is still J0.
Let R denote the samplerate, which could be any such as 44.1,48,88,96,... Consider the simplified chain when using a streamer and an external DAC connected via S/PDIF.
Storage -> Network -> Streamer -> S/PDIF Transmitter -> Cable -> S/PDIF Receiver -> DAC Chip
------------------------------ | ------------------- | ------ | --------------------------- |
------------------------------ | ----- Clock A ------ | ------ | ---------- Clock B ---------- |
------------------------------ | ------------------- | ------ | --------------------------- |
Again, from Storage to Streamer there are no AD nor DA stages, hence at Streamer the jitter in S remains J0. The clock colums signify that all components in a column are driven by the same clock to which they must be in perfect sync to avoid jitter. Because the jitter at Streamer is J0, so only consider the chain from Stremaer to the final conversion-stage.
When Streamer sends S to the DAC (S/PDIF Receiver + DAC Chip), it does so using the S/PDIF Transmitter at a rate R provided by the clock A. The DAC Chip performs DA at a rate given by the clock B. Let At be the time between the ticks of A, and Bt the same for B. Does it work?
Consider first the idealised dream-scenario, which entails mainly the following: a) There are perfect clocks such that At=Bt. The frequcy for both is simply R, b) the S/PDIF Transmitter, Cable, and S/PDIF Receiver are 100% jitter-free. c) there is no delay, nor jitter, from the S/PDIF Receiver to the DAC-Chip. Given these assumptions the entire system works by letting B synchronise on the first incoming bit*. The system now clearly does not add any jitter at all. The amount of which at at the DAC-Chip is simply the good old J0.
Obviously, none of the above are real-world realisable. Until now most DAC chip producers have solved this by letting B be derived from A which is encoded in S. This is often refered to as: PLL, reclocking, ASRC, jitter-removal, jitter-elimination etc. Lets simply call it reclocking. Since B is now derived from S and dependent on A, lets call that clock B[A]=f(S) to signify that it depends on the signal S, via some procedure f. Pictorially:
Streamer -> S/PDIF Transmitter -> Cable -> S/PDIF Receiver -> Buffer -> DAC Chip
--------- | ------------------- | ------ | ----------------------------------- |
--------- | ----- Clock A ------ | ------ | ----------- Clock B[A] ------------- |
--------- | ------------------- | ------ | ----------------------------------- |
The Buffer is needed between that S/PDIF Receiver and the DAC Chip in order to do e.g. ASRC.
Now how does this setup relate to the dream-scenario: Ad. b) Here jitter occurs, and this is of the kind often refered to by terms such as: s/dpif generated jitter or transport-jitter. Lets call J1'. The [u]crux of the matter[/u] is that as far as jitter goes, any differences between the e.g. the Transporter and the SB3 is represented in J1'. Ad. a) Now because of J1' influence on S, the reclocking function f can in general never guarantee to obtain exactly the clock A from S. It will leave some remains of J1', which can be called J1. Ad. c) Clearly it does not hold in the theoretical sense cf. the speed of light. However the delay is neglible. Nonetheless because of this, and since the three components driven by B[A] can not be 100% synchronised, jitter does occur here. Lets call this J2. So the system is now real-world working, but at the cost of a total jitter at the DAC Chip of J0+J1+J2.
======================== PART II ========================
Now lets try and aim in on the solution used in the Naim DAC. The jitter J2 is not possible to get rid of as such**. So J1 is the target. J1 ultimately resulted because of the insufficiency of the reclocking-design. Lets backtrack and reconsider the first solution, but loose the assumption a). If it worked, there would be two independent stable clocks so J1 would be eliminated. Leaving jitter at the DAC Chip at the best possible result, wiz J0 + J1.
Unfortunately because of b) it doesn't work since no choice of stable clock B can match the jittery (c.f. b)) incoming signal. If A is too slow bits would be missed, and if its too fast there would be no availble bits from the S/PDIF Transmitter. Now lets combine and refine by adding a buffer as in the second solution and use two clocks in the DAC. One reclocking based B[A] for getting data into the DAC, and and another 100% local crystal oscilliator based B for clocking the signal out of the buffer and the DAC Chip. Pictorially:
Streamer -> S/PDIF Transmitter -> Cable -> S/PDIF Receiver -> Buffer -> DAC Chip
--------- | ------------------- | ------ | --------------- | ------------------ |
--------- | ------ Clock A----- | ------ | - Clock B[A] - | ----- Clock B ----- |
--------- | ------------------- | ------ | --------------- | ------------------ |
If now the average time (over some interval) between the ticks of B[A] was matched by B this would then work. More [u]importantly[u/], it would completely eliminate all jitter J1 since B is 100% local to the circuit clocking data out of the local buffer and driving the DAC Chip. Unfortunately such a fixed single clock B that would match all scenarios does not exist. B would very likely not match the average of the clock B[A]. Hence even the buffer would under- or overrun at some point. A helpful analogy is a waterhose with a tap at each end. Unless both taps (clocks) are set to exactly the same capasity, "holes" will occur, or "pressure" will build up. The buffer may be thought of as a finite volume resorvoir connected to the hose.
But this now hints at the final solution. Rather than fixing B at some predefined tick-rate (frequency), one simply makes available a set of 10 slightly different and cleverly chosen fixed local clocks. One of these will likely be a sufficiently close match to the average tick-rate of B[A] for the buffer not to under- or overrun***
Conclusion. The system therefore operationally works without the assumptions a), b), and c) at the lowest possible jitter level, J0+J2. In particular it is independent of the jitter J1 and J1'. It is essentially nothing but a good practical solution to the "waterhose" problem mentioned above.
Bjørn
=======================================================================================
PS If you made it here, please comment.
PSS I have deliberaty not mentioned bit-errors in transmissions. In the above, they are practically possible only from the stage of the S/PDIF Transmitter and onwards. Statistically the likelihood of such errors is extremely low AFAIK.
PSSS It is true that B may end up running at A+E. This is not jitter.
PSSSS There are too many simplifications in the above to detail them all. But please comment if I've made any that could alter the conclusion.
PSSSSS Since the secondary clock in the Naim DAC is truly independent of the clock in the transport I'd rather not use the term reclocking as it, in my book, implies a functional relationship between the two
PSSSSSS I haven't heard it... yet
* This is not really feasible in general, but its a harmless assumption that becomes voided in a few lines.
** This kind of intrisic jitter obviously varies between devices depending on the quality of those. Naim has a good design and probably very low jitter at this stage.
*** I understand from others that such a match is indeed, for all intents and purposes always found, as can be seen by an indicator-light on the DAC.
Hi fatcat (strange greeting someone using that word
Thanks for your reply. Sorry mine is late: I simply did not notice until now.
Indeed, and this should be covered in my 1. post. I could perhaps add that what lead me to write the 1. post was discussions regarding the difference between digital transports when feeding a Naim DAC - hence the springing point, jitterwise, is s/pdif introduced jitter.
Well, all I can say is that they are In fact they compensate for inaccuracies in the entire S/PDIF chain. The matching issue is a springing point. However there is a light on the front of the DAC which lights up when sufficiently good match is found. Several of those who have actually seen/heard the DAC in action reports to never have seen this not on. Also Naim write in the whitepaper that a match is very likely to be found. Obviously, this is configuration-dependant, and I guess the exact match/no match ratio will only become known when the DAC has seen more widespread use.
I'm not sure I am with you here. Surely a transport feeding the DAC with a 16/44 signal, would also use a clock as close as possible to 44 - alternatively one that can be precisely scaled to that rate?
Thanks for your reply. Sorry mine is late: I simply did not notice until now.
quote:Originally posted by fatcat:
The S/PDIF interface carries the data stream, plus, it also carries the timing information used by the DAC to construct the analogue waveform. The Naim DAC eliminates the S/PDIF interface induced timing jitter but doesn’t eliminate other forms of jitter.
Jitter Explained
Indeed, and this should be covered in my 1. post. I could perhaps add that what lead me to write the 1. post was discussions regarding the difference between digital transports when feeding a Naim DAC - hence the springing point, jitterwise, is s/pdif introduced jitter.
quote:Originally posted by fatcat:
I suspect the 10 carefully selected clock speeds used in the DAC aren’t to accommodate inaccuracies in the transport clock. It’s due to the fact different manufactures use different clock speed.
Well, all I can say is that they are
In fact they compensate for inaccuracies in the entire S/PDIF chain. The matching issue is a springing point. However there is a light on the front of the DAC which lights up when sufficiently good match is found. Several of those who have actually seen/heard the DAC in action reports to never have seen this not on. Also Naim write in the whitepaper that a match is very likely to be found. Obviously, this is configuration-dependant, and I guess the exact match/no match ratio will only become known when the DAC has seen more widespread use.quote:Originally posted by fatcat:
Ranging from 8.4672 To 45.1584 MHz
Pioneer PD-9700 16.9344MHz
Pioneer PDR-04 16.9344MHz
PS Audio Lambda 11.2896MHz
Technics SL PS670A 33.868MHz
Nad 5425 33.868MHz
Nakamichi 16.9344MHz
Sony X779 ES 45.1584MHz
I'm not sure I am with you here. Surely a transport feeding the DAC with a 16/44 signal, would also use a clock as close as possible to 44 - alternatively one that can be precisely scaled to that rate?
quote:Originally posted by bhaagensen:quote:Originally posted by fatcat:
I suspect the 10 carefully selected clock speeds used in the DAC aren’t to accommodate inaccuracies in the transport clock. It’s due to the fact different manufactures use different clock speed.
Well, all I can say is that they arequote:Originally posted by fatcat:
Ranging from 8.4672 To 45.1584 MHz
Pioneer PD-9700 16.9344MHz
Pioneer PDR-04 16.9344MHz
PS Audio Lambda 11.2896MHz
Technics SL PS670A 33.868MHz
Nad 5425 33.868MHz
Nakamichi 16.9344MHz
Sony X779 ES 45.1584MHz
I'm not sure I am with you here. Surely a transport feeding the DAC with a 16/44 signal, would also use a clock as close as possible to 44 - alternatively one that can be precisely scaled to that rate?
Bjorn
Well, I am 99.99% sure they aren’t.
Below are more examples of clock frequencies used in various machines.
Naim CD5 16.9344MHz
Naim NA CD3 16.9344MHz
Meridian 500 11.2896MHz
Meridian 506 11.2896MHz
Arcam 70.2/ 70.3 11.2896MHz
Arcam 170.3 11.2896MHz
Sony 761 45.1584MHz
Quad 66 11.2896MHz
Quad 67 11.2896MHz
Sony CDP 497 22.5792MHz
Sony CDP 555 ES 16.9344MHz
There appear to be 10 common oscillator speeds between 8.4672 and 45.1584 MHz.
The Naim DAC identifies the clock frequency of the transport, if DAC contains an oscillator of the same frequency the sync light illuminates.
Pioneer DVD players use a frequency of 27.0000MHz. This is uncommon, I would expect the DAC not to sync. If I could turn on the digital output of my DV717 on, I could confirm this.
I can confirm that a good Rotel CD player fitted with a high performance clock performs better than a Toshiba DVD player costing £300. Even when the DVD player is spinning a DVD Audio disc.
quote:Originally posted by bhaagensen:
Makes sense?
A little, but that’s my fault not yours.
Thanks for explaining oscillator base frequency.However, are you now stating the Naim DAC clocks are set to 44.1, 48, 88, 96 etc, and not to 10 slightly different speeds.
quote:Also note that the crystal oscillator in the DAC does not need to have the same frequncy as the crystal oscillator in the Transport because - well as I said, it is only used for deriving. Of course here the point is that the Naim DAC uses the former for receiving data in its buffer and the latter independent local crystal clock for driving the DAC Chip. Hence (s/pdif) jitter is completely removed.
The above being correct, the Naim DAC uses the transport clock when interpreting the data stream entering the buffer. It therefore follows that the accuracy of the data entering the buffer is dependent on the accuracy of the clock information that is transmitted through the S/PDIF. Data that is lost during this process is lost for ever. Reclocking the information in the buffer, won’t recover the lost data.