Synchronuous reclocking (ddac) - no clicks ?

pawelp · 10th February 2009, 03:54 PM

There is 1 thing that has been quite bothering me for some time. I have tested out pretty well to confirm ASRC is actually no good for really demanding ears while DDAC philosophy of clocking the SPDIF receiver such as 8412/14 with a clean local clock seems really appealling and cheap. The only thing is I am not sure how it works, I mean it loses occasionally samples and that should be heard as quite disturbing and non-high-end clicks. With so many people having made it and reported nice listening experiences I am just wondering - are there actually no clicks in this setup ? I have studied 8412 datasheet but they do not elaborate on that. Actually I can imagine that putting out the last correct sample value twice and smart resynchronizing to the SPDIF stream could maybe result in no clicks which are in essence signal discontinuities. Or are these clicks so rare that no-one bothers ? Can someone enlighten me on that or just empirically tell how this works in practice.

Pawel

justblair · 10th February 2009, 06:40 PM

I can report no clicks with my usb DDDAC. I am not qualifiied to explain the technicalities of the DACs reclocking.

Sound wise I can report I really like it. I have two DAC boards, ie 24 chips in parrallel. And like the sound imensly. I can only really compare with the Cambridge Audio DAC1 that I used before and can say the improvement is huge in all areas.

pawelp · 10th February 2009, 08:29 PM

Thanks for the info, justblair. You probably have DDDAC 1543 mk2 - like board ? As this is a USB only (no SPDIF) one then there is actually no reclocking at least in the form I referred to - I meant the version with SPDIF reclocking. Seems worth trying out though.

justblair · 10th February 2009, 09:06 PM

Doh.

Didn't think I typed!

Yes mine is the MK2 version. And USB at that.

rbroer · 11th February 2009, 09:58 AM

Quote:

Originally posted by pawelp
I have studied 8412 datasheet but they do not elaborate on that.Pawel

From the datasheet:
When FSYNC and SCK are inputs, one stereo sample is double buffered.
and:
If the circuit generating SCK and FSYNC is not locked to the master clock, the serial port will eventually be reread or a sample will be missed.

DDDAC is still reclocking asynchronously, but it's conviently done in the DIR, which has double buffers onboard to overcome any metastability issues (that is clicks).

See also:
http://en.wikipedia.org/wiki/Metastability
http://en.wikipedia.org/wiki/Double_buffering
http://www.eetimes.com/editorial/2000/design0003.html

Cheers,

pawelp · 11th February 2009, 08:22 PM

Thanks for the input. I hope you do not mind some follow-up questions.
I assume your point is double bufferring eliminates clicks. How can buffering eliminate something when the receiving clock is faster than the source clock - it has not got into any buffer, no matter if double ?
And when it drops a sample how can it still work without significant distortion when the bits on both sides (source and receiving) are shifted ? Doesn't there have to be a resynchronization mechanism to put bit significance back in order ?
I do not understand how this metastability applies to clicks - the clicks I have in mind are not some transient states in IC-s but simple incorrect output physical voltage function manifesting itself as a drop or peak due to a drop of a sample.
And I have always thought the whole idea works because the source and receiving clocks are very close in frequency. That would mean drops are infrquent and bearable. If it is truly asynchronous it should also work well in an e.g. 44,1 + 48 kHz configuration. Is it really the case or is it rather asynchronuous that actually tries to simulate synchronous ?

gaetan8888 · 12th February 2009, 12:40 AM

Hello

Lot of time, with asynchronous reclock, there is a clock differences between the local clock and the one of the transport.

So the big questions are; do the DDDac way's of asynchronous reclock with buffering, does reduce jitter, and is it better in result and in sound compared to others asynchronous reclock ?

Synchronous reclock are much complicated.

Is there simple schematic circuit of a good synchronous reclock ?

Bye

Gaetan

pawelp · 12th February 2009, 05:46 AM

Come on, I am not an expert in electronics but DDDAC is not a proper asynchrouous reclocking e.g. the way AD1836 ASRC does it - for that you need some FIFO, I cannot see it different. In AD1836 (more precisely in its implementation in Sharc) there is a 512 deep FIFO for both channels + FIR filtering to interpolate samples. What would be the equivalent functionality of 8412/14 ?

pawelp · 12th February 2009, 11:07 AM

This topic aroused emotions some time ago already:
Reclocking the SPDIF line
A quote from this:

CS8412 has also some specific predefined behaviours in case the SCK and FSYNC clocks are asynchronous to the input flow. In case a new word is requested by FSYNC clock before a new one has been read, an error flag is raised, but there is no "hole" in the output data flow: the old sample is re-output again.

See http://www.tnt-audio.com/clinica/convertusdecdig_e.html

Anyway,

If you have a source with a clock which is slower than the DAC's, you will get double samples into the DAC. If you have a source with a faster clock, you will loose samples from time to time.

But it can still sound better than the normal jittery connection......

If you want to get around this: use a pll or feed the clock back to the transport.

Greetings,

GuidoB

CS8412 has also some specific predefined behaviours in case the SCK and FSYNC clocks are asynchronous to the input flow. In case a new word is requested by FSYNC clock before a new one has been read, an error flag is raised, but there is no "hole" in the output data flow: the old sample is re-output again.
See http://www.tnt-audio.com/clinica/convertusdecdig_e.html

Anyway,

If you have a source with a clock which is slower than the DAC's, you will get double samples into the DAC. If you have a source with a faster clock, you will loose samples from time to time.

But it can still sound better than the normal jittery connection......

If you want to get around this: use a pll or feed the clock back to the transport.

Greetings,

GuidoB

I am much closer to this explanation than metastibiliy and asynchronous resampling.
But I would like to go a step further, let's imagine two consecutive SPDIF words: A1 and A2, and let's assume SPDIF is based on 4-bit instead of 20/24 as in the reality.
A1: 1 0 1 1 (MSB first)
A2: 0 1 1 0
The output clock is faster than the source clock:
The SPDIF receiver reads A1: 1 0 1 1 - and here it the output requires another sample.
OK, CS repeats the last - 1, so on the output we get
A2: 1 (instead of zero). What happens then ? Source still has another original four bits 0 1 1 0 to be passed to the output. But then everything goes to hell because the original bits of A2 (0 1 1 0) become the next bits after the 1 that was repeated. As I try such setups using the flexible Sharc DSP processor I know how it sounds - it plays very well 1 minute, 2, 3, depends but then it gets so distorted you can hardly hear the sound through it.
But with some intelligence on the chip, like if the a sample was used twice then skip the next one - OK that can work with relatively rarely (like one in 64 times you would get a sample miss on the MSB which could be really audible, the others next to none and rarely).
Why am I following this in such a detail ? This is a very simple algorithm and it could allow for a very simple perfect attainable reclocking, i.e. local, low-jitter clock, very slightly not-bit-perfect. I have a choice of a much more complex design with programmed wave genearators whereas this one can be much cheaper and possibly even better (extremely low jitter from a local quartz).

10th February 2009, 03:54 PM	#1
pawelp diyAudio Member Join Date: May 2006	Synchronuous reclocking (ddac) - no clicks ? There is 1 thing that has been quite bothering me for some time. I have tested out pretty well to confirm ASRC is actually no good for really demanding ears while DDAC philosophy of clocking the SPDIF receiver such as 8412/14 with a clean local clock seems really appealling and cheap. The only thing is I am not sure how it works, I mean it loses occasionally samples and that should be heard as quite disturbing and non-high-end clicks. With so many people having made it and reported nice listening experiences I am just wondering - are there actually no clicks in this setup ? I have studied 8412 datasheet but they do not elaborate on that. Actually I can imagine that putting out the last correct sample value twice and smart resynchronizing to the SPDIF stream could maybe result in no clicks which are in essence signal discontinuities. Or are these clicks so rare that no-one bothers ? Can someone enlighten me on that or just empirically tell how this works in practice. Pawel

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Decoder output: how jittery, worth reclocking? And "double" reclocking	hollowman	Digital Source	0	17th July 2009 01:39 PM
VCA clicks	YureZzZ	Analog Line Level	2	1st December 2007 06:07 PM
Mains pops and clicks	markiemrboo	Chip Amps	10	9th September 2007 09:57 AM
My DDAC Case	justblair	Digital Source	11	24th August 2007 10:35 PM

New To Site?	Need Help?
Register to Participate Search Privacy Statement Contact Us	Frequently Asked Questions Did you forget your password? Mark Forums Read


	Please consider donating to help us continue to serve you. Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving

10th February 2009, 06:40 PM	#2
justblair diyAudio Member Join Date: Jan 2007 Location: Glasgow, Scotland	I can report no clicks with my usb DDDAC. I am not qualifiied to explain the technicalities of the DACs reclocking. Sound wise I can report I really like it. I have two DAC boards, ie 24 chips in parrallel. And like the sound imensly. I can only really compare with the Cambridge Audio DAC1 that I used before and can say the improvement is huge in all areas.

10th February 2009, 08:29 PM	#3
pawelp diyAudio Member Join Date: May 2006	Thanks for the info, justblair. You probably have DDDAC 1543 mk2 - like board ? As this is a USB only (no SPDIF) one then there is actually no reclocking at least in the form I referred to - I meant the version with SPDIF reclocking. Seems worth trying out though.

10th February 2009, 09:06 PM	#4
justblair diyAudio Member Join Date: Jan 2007 Location: Glasgow, Scotland	Doh. Didn't think I typed! Yes mine is the MK2 version. And USB at that.

11th February 2009, 08:22 PM	#6
pawelp diyAudio Member Join Date: May 2006	Thanks for the input. I hope you do not mind some follow-up questions. I assume your point is double bufferring eliminates clicks. How can buffering eliminate something when the receiving clock is faster than the source clock - it has not got into any buffer, no matter if double ? And when it drops a sample how can it still work without significant distortion when the bits on both sides (source and receiving) are shifted ? Doesn't there have to be a resynchronization mechanism to put bit significance back in order ? I do not understand how this metastability applies to clicks - the clicks I have in mind are not some transient states in IC-s but simple incorrect output physical voltage function manifesting itself as a drop or peak due to a drop of a sample. And I have always thought the whole idea works because the source and receiving clocks are very close in frequency. That would mean drops are infrquent and bearable. If it is truly asynchronous it should also work well in an e.g. 44,1 + 48 kHz configuration. Is it really the case or is it rather asynchronuous that actually tries to simulate synchronous ?

12th February 2009, 12:40 AM	#7
gaetan8888 diyAudio Member Join Date: Apr 2007	Hello Lot of time, with asynchronous reclock, there is a clock differences between the local clock and the one of the transport. So the big questions are; do the DDDac way's of asynchronous reclock with buffering, does reduce jitter, and is it better in result and in sound compared to others asynchronous reclock ? Synchronous reclock are much complicated. Is there simple schematic circuit of a good synchronous reclock ? Bye Gaetan

12th February 2009, 05:46 AM	#8
pawelp diyAudio Member Join Date: May 2006	Come on, I am not an expert in electronics but DDDAC is not a proper asynchrouous reclocking e.g. the way AD1836 ASRC does it - for that you need some FIFO, I cannot see it different. In AD1836 (more precisely in its implementation in Sharc) there is a 512 deep FIFO for both channels + FIR filtering to interpolate samples. What would be the equivalent functionality of 8412/14 ?

12th February 2009, 11:07 AM	#9
pawelp diyAudio Member Join Date: May 2006	This topic aroused emotions some time ago already: Reclocking the SPDIF line A quote from this: CS8412 has also some specific predefined behaviours in case the SCK and FSYNC clocks are asynchronous to the input flow. In case a new word is requested by FSYNC clock before a new one has been read, an error flag is raised, but there is no "hole" in the output data flow: the old sample is re-output again. See http://www.tnt-audio.com/clinica/convertusdecdig_e.html Anyway, If you have a source with a clock which is slower than the DAC's, you will get double samples into the DAC. If you have a source with a faster clock, you will loose samples from time to time. But it can still sound better than the normal jittery connection...... If you want to get around this: use a pll or feed the clock back to the transport. Greetings, GuidoB CS8412 has also some specific predefined behaviours in case the SCK and FSYNC clocks are asynchronous to the input flow. In case a new word is requested by FSYNC clock before a new one has been read, an error flag is raised, but there is no "hole" in the output data flow: the old sample is re-output again. See http://www.tnt-audio.com/clinica/convertusdecdig_e.html Anyway, If you have a source with a clock which is slower than the DAC's, you will get double samples into the DAC. If you have a source with a faster clock, you will loose samples from time to time. But it can still sound better than the normal jittery connection...... If you want to get around this: use a pll or feed the clock back to the transport. Greetings, GuidoB I am much closer to this explanation than metastibiliy and asynchronous resampling. But I would like to go a step further, let's imagine two consecutive SPDIF words: A1 and A2, and let's assume SPDIF is based on 4-bit instead of 20/24 as in the reality. A1: 1 0 1 1 (MSB first) A2: 0 1 1 0 The output clock is faster than the source clock: The SPDIF receiver reads A1: 1 0 1 1 - and here it the output requires another sample. OK, CS repeats the last - 1, so on the output we get A2: 1 (instead of zero). What happens then ? Source still has another original four bits 0 1 1 0 to be passed to the output. But then everything goes to hell because the original bits of A2 (0 1 1 0) become the next bits after the 1 that was repeated. As I try such setups using the flexible Sharc DSP processor I know how it sounds - it plays very well 1 minute, 2, 3, depends but then it gets so distorted you can hardly hear the sound through it. But with some intelligence on the chip, like if the a sample was used twice then skip the next one - OK that can work with relatively rarely (like one in 64 times you would get a sample miss on the MSB which could be really audible, the others next to none and rarely). Why am I following this in such a detail ? This is a very simple algorithm and it could allow for a very simple perfect attainable reclocking, i.e. local, low-jitter clock, very slightly not-bit-perfect. I have a choice of a much more complex design with programmed wave genearators whereas this one can be much cheaper and possibly even better (extremely low jitter from a local quartz).