Regal wrote:
IF slaving the transport makes irrelevant the "transport's quality", then one could save $ with "entry level" transports like NAD521BEE.
(I sold my NAD542 and bought CDPRO-2M for the same amount)
(I'm like an old lady from an ancient film who tryes everything that is advertised on TV!
)
Keep on talking, gentlemen...
IF slaving the transport makes irrelevant the "transport's quality", then one could save $ with "entry level" transports like NAD521BEE.
(I sold my NAD542 and bought CDPRO-2M for the same amount)
Yes? Who's calling...?
(I'm like an old lady from an ancient film who tryes everything that is advertised on TV!
)Keep on talking, gentlemen...
Ulas said:
Not quite. I'm talking about two patch cord coax cables, one for the SPDIF signal, and the 2nd carries a jitter free clock from the master clock oscillator to replace that normally made by the DAC box's PLL circuit. This clock would run the DAC chip directly (or thru a simple divide down).
wa2ise said:
First of all, there is no such thing as a jitter-free clock except in a clockmonger’s wet dream. Second, anything you do to a clock, such as, put it through a driver and send it down a wire, etc. adds noise, slows the transition time, and increases jitter. Third, if the DAC must get its master clock from the CDP, the DAC is unusable without that modified CDP. Look at the diagram I posted. With the master clock in the DAC you have a choice of using the master clock for all DAC clocks or the clocks derived from S/PDIF.
Exactly why do you insist the master clock must be located in the CDP and not the DAC? What are the benefits?
Ulas said:
Okay, but what i was thinking was that the jitter from the drivers and sending it down that wire would be much less than jitter from a PLL. To a level that doesn't matter anymore. But now that I think of it, you're right. Just locate the master clock next to the DAC chip in the DAC box. Then even that jitter doesn't happen. Just the jitter inherent in the master oscillator itself (hopefully low enough to not be a problem). Only reason I had in mind with the master clock in the CDP was to avoid clock timing skews you'd get if the clock had to run thru some unknown length of coax cable to the CDP and then the data coming back from the CDP to the DAC box thru another unknown length of coax cable. You'd have an unknown phasing of the clock to the transisions of the data bits, which can be nasty if you try to strobe in the middle of a transision.
Why can't you just feed a DAC (say a PCM1794) with local, low-jitter version of what was in your CD player and then feed that back to the player?
Isn't the system clock input in a DAC ultimately driving the output - and aren't the i2s lines just feeding internal registers?
Wouldn't all timing errors (as s/pdif is spec'd to not allow for data errors) become irrelevant as the DAC clocked the i2s data into whatever mechanism it uses to generate an analog signal?
Or am I missing something? Or many things?
Or is the issue that the transitions of the i2s lines vs the clock could come far enough out of (or in) sync as to cause problems?
I can't imagine a finite delay of info caused by the i2s - s/pdif - i2s conversion would have any effect - just as setting a kitchen clock one minute ahead doesn't affect its ability to count accurately.
Isn't the system clock input in a DAC ultimately driving the output - and aren't the i2s lines just feeding internal registers?
Wouldn't all timing errors (as s/pdif is spec'd to not allow for data errors) become irrelevant as the DAC clocked the i2s data into whatever mechanism it uses to generate an analog signal?
Or am I missing something? Or many things?
Or is the issue that the transitions of the i2s lines vs the clock could come far enough out of (or in) sync as to cause problems?
I can't imagine a finite delay of info caused by the i2s - s/pdif - i2s conversion would have any effect - just as setting a kitchen clock one minute ahead doesn't affect its ability to count accurately.
Thought I'd just ressurect this thread as I have just built a simple circuit (on veroboard) that generates a S/PDIF signal for a soundcard to slave to. I'm not going to take any credit for the circuit, it's basically the right hand side of this: http://ece.uprm.edu/~hunt/src.htm with a 74HC04 buffer and TOTX177 Toslink output connector providing the isolation instead of a transformer. The master clock for the CS8402CP comes in, again over Toslink, via a TORX177 and another 74HC04 buffer.
The DAC is a Cambridge Audio IsoMagic which provides a 128Fs Clock (5.6448MHz) over Toslink when switched into clock-lock mode so no work to do there.
The Soundcard is a RME HDSP9632 which syncronises to an Optical S/PDIF input, although I believe a lot of professional soundcards will do this.
It does use the obsolete CS8402CP, however this is available in a skinny DIL package so no surface mount soldering is required! As a surface-mount virgin I saw this as a major plus.
If anyone wants the actual circuit I'm sure I could draw it but I think most of the information is here.
I was surprised at how easy it was given all that I had read but I guess I didn't have to do any modifications to the DAC or transport(soundcard). I think this approach would be valid for any clock frequency, the common ones would just need dividing down first.
Simon
The DAC is a Cambridge Audio IsoMagic which provides a 128Fs Clock (5.6448MHz) over Toslink when switched into clock-lock mode so no work to do there.
The Soundcard is a RME HDSP9632 which syncronises to an Optical S/PDIF input, although I believe a lot of professional soundcards will do this.
It does use the obsolete CS8402CP, however this is available in a skinny DIL package so no surface mount soldering is required! As a surface-mount virgin I saw this as a major plus.
If anyone wants the actual circuit I'm sure I could draw it but I think most of the information is here.
I was surprised at how easy it was given all that I had read but I guess I didn't have to do any modifications to the DAC or transport(soundcard). I think this approach would be valid for any clock frequency, the common ones would just need dividing down first.
Simon
The soundcard can be slaved (synchronised) to the incoming SPDIF signal. I would love to see the circuit.
I have been trying to make a curcuit for CS8402 and asked others to do it for me. Unfortunately I haven't arrived at any solution because I am not that well versed in digital electronics.
I have been trying to make a curcuit for CS8402 and asked others to do it for me. Unfortunately I haven't arrived at any solution because I am not that well versed in digital electronics.
What is the intention of slaving the transport to the DAC ?
Directly connecting the divided clock to the DAC's latch enable input or reclocking the latch enable with the undivided clock ?
I installed a 256fs clock in my nonos DAC, the clock is divided by a hc590 to 1fs and sent back to the transport which expects a 1fs word clock.
The latch enable signal in the DAC is reclocked by a hc74 with 256fs.
Works fine, but also with a standard spdif, shouldn't there be any problems if it is not in sync ?
Maybe it introduces a lot of jitter, I did not listen closer, just checked go-no go...
What does not work is feeding the latch enable inputs directly with the divided clock. Sound is totally distorted.
Comparing the signals from CS8412 and divided clock shows that the divided clock is too late for 160ns or even inverted and 160ns off.
There is a pot in the transport for phase adjust but before the signals match, the transport does not lock anymore to the word clock and no spdif.
Could it help to delay the spdif stream ?
Any comments ?
Directly connecting the divided clock to the DAC's latch enable input or reclocking the latch enable with the undivided clock ?
I installed a 256fs clock in my nonos DAC, the clock is divided by a hc590 to 1fs and sent back to the transport which expects a 1fs word clock.
The latch enable signal in the DAC is reclocked by a hc74 with 256fs.
Works fine, but also with a standard spdif, shouldn't there be any problems if it is not in sync ?
Maybe it introduces a lot of jitter, I did not listen closer, just checked go-no go...
What does not work is feeding the latch enable inputs directly with the divided clock. Sound is totally distorted.
Comparing the signals from CS8412 and divided clock shows that the divided clock is too late for 160ns or even inverted and 160ns off.
There is a pot in the transport for phase adjust but before the signals match, the transport does not lock anymore to the word clock and no spdif.
Could it help to delay the spdif stream ?
Any comments ?
Last edited:
With standard spdif or disconnected, when triggering a scope on the rising edge of latch enable before the reclocker, then the recklocked signal is unstable with variations of up to 90ns which is pretty much one cycle of the clock.
As soon as the slaved transport locks to the wordclock, it is stable.
As soon as the slaved transport locks to the wordclock, it is stable.
I don't know if you have seen my thread on this stuff:
http://www.diyaudio.com/forums/digital-line-level/140232-slaving-audio-board-mck-dac-via-spdif.html
WARNING:
the circuit on the 1st post has an error the correct one is on this post:
http://www.diyaudio.com/forums/digi...io-board-mck-dac-via-spdif-5.html#post1909078
ciao
andrea
http://www.diyaudio.com/forums/digital-line-level/140232-slaving-audio-board-mck-dac-via-spdif.html
WARNING:
the circuit on the 1st post has an error the correct one is on this post:
http://www.diyaudio.com/forums/digi...io-board-mck-dac-via-spdif-5.html#post1909078
ciao
andrea
Thanks, so you do reclocking and not direct clock injection.
I still would like to know if there exist implementation where the divided DAC master clock is directly injected into the DAC chips, that would safe the flipflop.
About the synced / unsynced spdif:
The DAC master clock must be an integer multiple of the latch enable signal that enters the reclocker, which means the clocks in the DAC and in the transport must be synced.
So in a nonos DAC, each rising edge of the reclocked signal will be transferred by the reclocker after another 256 cycles of the 11,2896 MHz DAC master clock.
After the reclocker, every sample has the same length except for jitter of the DAC master clock.
If the transport is not slaved to the DAC, the clocks are not in sync and the frequencies of the clocks differ slightly.
It means that the cycles of the DAC master clock do not fit exactly into the cycle of the latch enable signal.
Referenced to the rising edge of the latch enable signal, the phase of the DAC master clock will move continously into one direction until after a number of samples a correction will occur.
Instead of 256 cycles of the 11,2896 MHz DAC master clock, the reclocker will output a sample that is 255 or 257 cycles long, depending on wether the clock is too fast or too slow.
That will result in a jitter pattern with singular timing deviations of one DAC master clock cycle = 89 ns.
No clicks or pops but jitter.
Correct me if I'm wrong.
Last edited:
I don' know if i have understood well all your post (my english is main cause) but i can tray to explain better my experience on this stuff.
On my board built from this circuit all the signals are synchronous to the MCK.
CS8402 (in mode 0) using MCK/2 generate the blank SPDIF signal to slave the transport (audio board setted to use SPDIF in as clock source) and BCK (bit clock) and WS (word clock), these three signals are synchronous.
CS8414 (in mode 3 - slave mode with double buffer) receive the SPDIF signal from the transport and "extract" from it the DATA signal using the aforementioned BCK and WS (these three signals are synchronous because the transport is slaved).
At this point DATA, WS and BCK are reclocked by flip flops using MCK for cleaning and aligning purposes but they are already synchronous.
If i use this board without sending the blank SPDIF slaving signal to the audio board i have MCK, BCK and WS synchronous but now DATA has no phase relation with these three signals (now it's synchronous with another MCK generated in the audio board setted to use internal clock source).
In this case i ear no clicks or pops but because of the double buffer in the CS8414 i have slipped or repeated samples every now and then (this comes from the fact that we have two asynchronous clock with frequency very close to each other but not equal, one in the transport and one in the DAC).
The slipped or repeated samples don't have a big impact on the audio quality, it's really difficult (for me) to distinguish from the way with slaved audio board (that anywy is the right way to have all synchronous signals with MCK on the DAC).
Ciao
Andrea
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.