Debate of DAC design regarding DSD vs PCM among 5 VIPs

[louisxiawei]

Interview with Andreas Koch from playback

 

2.3 How does your developed 2D DAC work?

 

The signal of the sound includes two axis that is X-axis: time and Y-axis: frequency and amplitude. In terms of the “analogue” music signal playback, we generally only need to care about the performance of this Y-axis. However, in the case of digital signal, not only the Y-axis matters but the accuracy of the X-axis also needs to be taken care of. The problem of most of dacs design is that they follow the rules of analogue playback, which only focus on the Y-axis of the music playback and let the complex clock synchronization circuit to operate the clock. They seem to forget that clock signal in fact is still a kind of analogue signal. Factors such as digital cables, the vibration of chassis cases, optical pickup and etc. will affect the performance of digital signal playback. These factors indeed have impact on the precision of analogue clock and produce the jitter as a result.

 

To solve the problem. We must rethink the role of the dac, and include the clock into one of the main tasks of the DAC design list. Our 2D DACs are designed based on this idea. As the term implies, 2D means 2 Dimensions indicating we pay attention on both X-axis and Y-axis.  

 

How does 2D dac work?  Before D-A conversion, 2D DAC will transmit the jitter along with the digital signal into the field of digital processing. By doing this, the jitter can be removed with the correct sampling clock and therefore, completely get rid of the jitter produced during the signal transmission.

[Ralf11]

15 hours ago, Nikhil said:

 

The problem I have is that whatever people say negatively about DSD, it doesn't bear with what I hear in my setup.  

If you take the trouble to make the investment in the computing power needed to process DSD (and a DSD DAC), it is a very enjoyable sound.

 

 

 

How much computing power is needed to process DSD ?

[Nikhil]

6 hours ago, Ralf11 said:

 

How much computing power is needed to process DSD ?

 

This depends on the software strategy you want to use for playback i.e. pure DSD vs PCM to DSD conversion. 

Also depends on where you want to do the heavy lifting - on the server or on the DAC chip.

 

On Windows, JRiver or JPlay don't really need a lot of computing power for playback. 

Folks in this camp tend towards the minimal computing strategy and can run into problems running higher DSD rates. 

 

On the other hand HQPlayer and Bughead need huge number crunching ability.  .

Here you have folks adding on nvidia graphic cards (CUDA offload feature in HQP)  to machines with Core i7 processors to process DSD256/DSD512 rates.  The highest computing power is needed for direct DSD to DSD conversion i.e. DSD 128 to DSD256/512 and will stress out most machines without CUDA offload.  

 

About two or three years ago we had a discussion on this using the JRiver Benchmark Test (JRMark)

For running DSD64 the JRMark was around the 3000 mark on i3 processors

For DSD 128 it was around 4000 - 4500 mark so Core i5 processors and above.

For DSD 256 and higher a Core i7 processor would handle the number crunching. .
 

Most new machines with new motherboards and processors will not have a problem up to DSD128.

 

 

 

 

[louisxiawei]

Interview with Andreas Koch from playback

 

2.4 Do you really solve the jitter problem completely?

 

To solve the jitter problem, there are two things need to be dealt with. One of them is phase-locked loops (PLL) that used for clock synchronization. PLL itself actually can produce jitter and phase noise. Therefore, instead of PLL, we use our own developed technology called PDFAS (Playback Designs Frequency Arrival System) to take the charge of clock synchronization so as to eliminate the jitter from PLL.

 

There is another kind of jitter that is irrelevant to digital signal and already exists in the music signal during digital recording and post-editing. Digital signal does not have the ability to eliminate this jitter, but it can try to get rid of some negative impact of this jitter. How are we going to do it? We take advantage of the “good jitter” produced by the clock so as to form a “white noise” which does not cause any uncomfortable listening experience. Therefore, we can dilute and mask the “bad jitter” which may deteriorate the sound from the recording.

 

After tons of comparison tests, we find a traditional VCXO quartz oscillator that can produce 35-40 ps “good jitter” and it is good enough to mask the “bad jitter” existed in the signal from the recording.

[Superdad]

7 hours ago, louisxiawei said:

After tons of comparison tests, we find a traditional VCXO quartz oscillator that can produce 35-40 ps “good jitter” and it is good enough to mask the “bad jitter” existed in the signal from the recording.

 

So now jitter is like cholesterol?  There's "good" jitter and "bad" jitter?

---------

I went to my (digital) doctor: I told him I had the jitters.  He said take two flip-flops and call me when the track is over.  

[Miska]

56 minutes ago, Superdad said:

 

So now jitter is like cholesterol?  There's "good" jitter and "bad" jitter?

 

 

Not that I would talk about "good" or "bad" jitter, but he is probably talking about correlated jitter vs non-correlated jitter. So in this case to the similar effect as spread spectrum clocking.

[semente]

27 minutes ago, Miska said:

 

Not that I would talk about "good" or "bad" jitter, but he is probably talking about correlated jitter vs non-correlated jitter. So in this case to the similar effect as spread spectrum clocking.

 

How about euphonic jitter, is there such a thing? 

[Superdad]

21 hours ago, Miska said:

 

Not that I would talk about "good" or "bad" jitter, but he is probably talking about correlated jitter vs non-correlated jitter. So in this case to the similar effect as spread spectrum clocking.

 

That's what I figured he meant.  But it was late and night and I was just having some fun.  

 

[louisxiawei]

Interview with Andreas Koch from playback

 

2.5 Do you think the external ultra-precision atomic clock is very effective?

 

This kind of atomic clock is very accurate indeed, but in my opinion it is “too” precise, which not only removes the “bad jitter” but also eliminates the “good jitter”. Consequently, the “bad jitter” in the recording signal has not been suppressed and causes negative impact. We used to do an audition comparison test in practice between a 2ps atomic clock and the traditional clock we used. As a result, the traditional clock offers a better sounding and that’s why we give up using atomic clock and choose the traditional clock generator instead.

 

P.S. I have no clue about this paragraph especially " the atomic clock eliminate both good jitter and bad jitter, and bad jitter is not suppressed."

[yamamoto2002]

24 minutes ago, louisxiawei said:

Interview with Andreas Koch from playback

 

2.5 Do you think the external ultra-precision atomic clock is very effective?

 

This kind of atomic clock is very accurate indeed, but in my opinion it is “too” precise, which not only removes the “bad jitter” but also eliminates the “good jitter”. Consequently, the “bad jitter” in the recording signal has not been suppressed and causes negative impact. We used to do an audition comparison test in practice between a 2ps atomic clock and the traditional clock we used. As a result, the traditional clock offers a better sounding and that’s why we give up using atomic clock and choose the traditional clock generator instead.

 

P.S. I have no clue about this paragraph especially " the atomic clock eliminate both good jitter and bad jitter, and bad jitter is not suppressed."

 

Interesting read.

 

This is my guessing...

Good jitter == random jitter.

Bad jitter == periodic jitter or deterministic jitter or limit cycle noise.

Random jitter works effectively as some kind of dithering and it masks or suppresses noise tone appeared as vertical sharp peak in spectrum analyzer  ?

[Nikhil]

On 4/25/2017 at 0:44 PM, Superdad said:

 

I went to my (digital) doctor: I told him I had the jitters.  He said take two flip-flops and call me when the track is over.  

 

 

LOL!  Good one ... 

 

 

On 4/25/2017 at 1:43 PM, Miska said:

Not that I would talk about "good" or "bad" jitter, but he is probably talking about correlated jitter vs non-correlated jitter. So in this case to the similar effect as spread spectrum clocking

 

 Thanks for clarifying that.  

 

 

[yamamoto2002]

In my experience, random jitter is also bad jitter (noise floor moves up and down according to the audio signal level and it is very annoying) so this interview is interesting

[jabbr]

"Random" jitter probably means evenly distributed frequency offset or "white" whereas correlated jitter refers to "close in" or 1/f. Not sure this has anything to do with atomic clocks whose close in phase error isn't specified -- they don't really remove noise either because really long term frequency stability isn't very relevant 

[Miska]

3 hours ago, jabbr said:

"Random" jitter probably means evenly distributed frequency offset or "white" whereas correlated jitter refers to "close in" or 1/f. Not sure this has anything to do with atomic clocks whose close in phase error isn't specified -- they don't really remove noise either because really long term frequency stability isn't very relevant 

 

Correlated jitter is something that has distinct sidebands and is usually result of some systematic function leaking to the clock signal. J-test signal was designed to highlight this on I2S lines, where leakage from other lines to the critical clock line causes systematic frequency variation and thus distinct sidebands in DAC output spectrum. Another typical source of correlated jitter is mains hum leaking to the clock line, causing modulation at 50/100 or 60/120 Hz and multiples.

 

There are various different types of random jitter with different distributions. It is also possible to do "whitening" on the clock.

 

[jabbr]

43 minutes ago, Miska said:

 

Correlated jitter is something that has distinct sidebands and is usually result of some systematic function leaking to the clock signal. J-test signal was designed to highlight this on I2S lines, where leakage from other lines to the critical clock line causes systematic frequency variation and thus distinct sidebands in DAC...

 

Yes, sidebands are generally "close in" to the clock signal. If you measure in 1hz an up increments you tend to see distinct bands, whereas if sub-Hz measurements then those bands may fill in, aside from true harmonics 

[Miska]

5 minutes ago, jabbr said:

Yes, sidebands are generally "close in" to the clock signal. If you measure in 1hz an up increments you tend to see distinct bands, whereas if sub-Hz measurements then those bands may fill in, aside from true harmonics 

 

Yes, but what I mean is that there's also random jitter that has "close in" distribution, causing just widening base of the main lobe. Like random phase noise with Gaussian distribution. But this is of course not correlated.

 

[jabbr]

27 minutes ago, Miska said:

 

Yes, but what I mean is that there's also random jitter that has "close in" distribution, causing just widening base of the main lobe. Like random phase noise with Gaussian distribution. But this is of course not correlated.

 

If you look at phase error distributions they rise up as offset decreases. Three slopes are described. Random or "white" error causes the baseline. 1/f noise is the upslope. This error is correlated both for clocks as well as transistors / resistors etc.

 

so assuming the baseline is -140 dB/Hz and the 1Hz is -90, the white component is insignificant compared to correlated.

[Miska]

1 minute ago, jabbr said:

If you look at phase error distributions they rise up as offset decreases. Three slopes are described. Random or "white" error causes the baseline. 1/f noise is the upslope. This error is correlated both for clocks as well as transistors / resistors etc.

 

I'm not sure I'm following what are the two correlated factors you are talking about here?

 

Yes, I can see correlated jitter when I2S DATA leaks to MCLK causing variation in MCLK that is correlated with the DATA. But what is the systematic correlation factor pattern you are talking about?

[jabbr]

If you have a copy of Rubiola In referring to figure 2.10

[Miska]

1 minute ago, jabbr said:

If you have a copy of Rubiola In referring to figure 2.10

 

I don't know what you are talking about.

 

Random processes can have different distributions, just like different dithers (RPDF, TPDF, Gaussian, etc), but those are never correlated. Or different frequency distributions for audible noises, white, pink, brown, etc.

[Miska]

IOW, for example thermal noise in clock causes this widening of main lobe, because thermal noise makes the phase wobble, but thermal noise itself is completely random uncorrelated process. And thus that jitter widening caused by thermal noise is completely uncorrelated, although not white.

 

[jabbr]

The three types of noise are generally thermal, shot and flicker which is (1/f). I'm looking at Rubiola: Phase Noise and Frequency Stability in Oscillators (2009), particularly Ch 2 which discusses noise in electrical devices and how that results in phase error in clocks. It's more than signal leakage, rather some physics.

[jabbr]

Right it's the flicker noise which is correlated. Flicker is what really causes peaks to widen.

 

Thermal noise affects the baseline not the peak.

[Miska]

1 minute ago, jabbr said:

Right it's the flicker noise which is correlated. Flicker is what really causes peaks to widen.

 

Still, I don't know what kind of process you mean by flicker and how it is correlated. What is the other variable and how it is correlated?

[Miska]

4 minutes ago, jabbr said:

The three types of noise are generally thermal, shot and flicker which is (1/f). I'm looking at Rubiola: Phase Noise and Frequency Stability in Oscillators (2009), particularly Ch 2 which discusses noise in electrical devices and how that results in phase error in clocks. It's more than signal leakage, rather some physics.

 

Unfortunately lot of people only look at clocks and advertise "femtosecond" clocks, but those are such only when looked in isolation. What matters is how the clock looks like at the D-A stage's latch.

 

When you have I2S traces side by side on a board, very frequently they leak to each other, or PSU noises leak to the latch circuit. Or cellular phone's RF transmitter nudges the clock edges.

 

Phase noise and frequency stability of the oscillator itself is usually least of the problems...