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
Pawel
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.
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.
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.
pawelp said:
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,
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 ?
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 ?
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
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
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 ?
This topic aroused emotions some time ago already:
http://www.diyaudio.com/forums/showthread.php?threadid=21835&perpage=25&highlight=&pagenumber=2
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).
http://www.diyaudio.com/forums/showthread.php?threadid=21835&perpage=25&highlight=&pagenumber=2
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).
- Status
- Not open for further replies.