I'm intrigued by the following posted by FINNEYBEAR in the real/fake PCM63 thread:
From his comments, it sounds like taking the DIR9001 (which I have) and implementing an asynchronous reclocking circuit (which I can do) is a better solution than a secondary PLL after the CS8412....
QUOTE:
Got some free time tonight, let me rephrase the whole thing again. Let's start with DIR901.
1. DIR9001 already has a controller-PLL-vcxo loop inside. TI/BB even gives it a fancy name:
Sampling Period Adaptive Controlled Tracking system (SpAct)
2. TI claims that this PLL loop will only add on 50ps jitter. I can see in reality it's more like
100ps. Still a very impressive number, consider there are so many components involved.
3. The PIC-ADC-VCXO loop is just like a second layer of PLL loop after DIR9001
4. With a tiny buffer, the PLL has to react quickly to lock on the incoming signal.
5. Yes, you can adjust the filter in the loop to lock on incoming signal aggressively.
The PLL will keep locking on beautifully but this also means the output clock signal will
follow the input clock closly.
6. This means you are actually following the input jitter instead of reducing the jitter.
7. VCXO in frequency transition is a phase noise generator. You also have to count in the extra
jitter generated by the components in the loop.
8. In short, this loop is not much different from the PLL loop inside DIR9001. This redundant
layer will just add more jitter to the signal.
9. To reduce jitter, you will have to create a circuit with high Q value, i.e. the output
clock and data should stay as stable as possible when the input keep changing.
A properly built buffer/FIFO control is one major solution.
Now go back to the ground zero:
1. If the SPDIF is clean, DIR9001 will do a job good enough. One extra loop with tiny buffer
most likely will just follow DIR9001's output and increase jitter
2. If the SPDIF is clean, DIR9001 + ASRC will be an attractive solution because ASRC has
a decent size buffer and the read out clock definitely has low jitter. Currently this is a very
popular option.
3. If the SPDIF is dirty, DIR9001 will struggle to follow the input, the second loop
will be busy with catching up all the input change, too.
4. CS8412/8414 has a relatively noisy PLL loop. In some scenarios, the second PLL with small
buffer may actually remove some jitter. Yet dont bet on this.
5. Therefore, it's much more beneficial to get a clean SPDIF output at the first place.
END QUOTE
From his comments, it sounds like taking the DIR9001 (which I have) and implementing an asynchronous reclocking circuit (which I can do) is a better solution than a secondary PLL after the CS8412....
QUOTE:
Got some free time tonight, let me rephrase the whole thing again. Let's start with DIR901.
1. DIR9001 already has a controller-PLL-vcxo loop inside. TI/BB even gives it a fancy name:
Sampling Period Adaptive Controlled Tracking system (SpAct)
2. TI claims that this PLL loop will only add on 50ps jitter. I can see in reality it's more like
100ps. Still a very impressive number, consider there are so many components involved.
3. The PIC-ADC-VCXO loop is just like a second layer of PLL loop after DIR9001
4. With a tiny buffer, the PLL has to react quickly to lock on the incoming signal.
5. Yes, you can adjust the filter in the loop to lock on incoming signal aggressively.
The PLL will keep locking on beautifully but this also means the output clock signal will
follow the input clock closly.
6. This means you are actually following the input jitter instead of reducing the jitter.
7. VCXO in frequency transition is a phase noise generator. You also have to count in the extra
jitter generated by the components in the loop.
8. In short, this loop is not much different from the PLL loop inside DIR9001. This redundant
layer will just add more jitter to the signal.
9. To reduce jitter, you will have to create a circuit with high Q value, i.e. the output
clock and data should stay as stable as possible when the input keep changing.
A properly built buffer/FIFO control is one major solution.
Now go back to the ground zero:
1. If the SPDIF is clean, DIR9001 will do a job good enough. One extra loop with tiny buffer
most likely will just follow DIR9001's output and increase jitter
2. If the SPDIF is clean, DIR9001 + ASRC will be an attractive solution because ASRC has
a decent size buffer and the read out clock definitely has low jitter. Currently this is a very
popular option.
3. If the SPDIF is dirty, DIR9001 will struggle to follow the input, the second loop
will be busy with catching up all the input change, too.
4. CS8412/8414 has a relatively noisy PLL loop. In some scenarios, the second PLL with small
buffer may actually remove some jitter. Yet dont bet on this.
5. Therefore, it's much more beneficial to get a clean SPDIF output at the first place.
END QUOTE
spzzzzkt said:
Paul,
The solution of 'ADD-ing' P6 of U4 with DG of U2 seems perfect to me. Both edges of LATCH are in the 'quit zone' of the stopped clock and you are sure the time between LE and the intake of the next DATA-word is large enough. Perfect.
Moreover, there is no 'cross talk' into the DATA by the LATCH positive edge. What do you want more?
In some changes you must believe that they are right. This is one of them.
Trying to decide every step by listening could work back-to-front. It could very well be that together with another change will give again a different answer. This makes mad! I left this method already long ago. For some updates you should believe in yourself and stick to: "This must be better". Sometimes much later it is corroborated.
The marvellous update: 'ADD U4/p6 with U2/DG' is such an update. It cannot be better. Trust yourself! Moreover, in my configuration it sounds better too.
Loudness:
One of my experiences is that you can play very loudly with good installations whithout any stress, while less good installations give stress at much lower audio levels.
Another experience is that if an update (eg. in a speaker-filter) seems to perform less loud (actually measurements tell the same level) then before, the update is an enhancement!
XO and power supply in the transport
You could put the Tent XO on the XO3 (?) board of TentLabs, which enhances the SPDIF as well.
Tentlabs also has separate power supplies for it, but also look after their low noise stabilisers which could replace the ordinary one(s).
spzzzzkt said:
You could put the Tent XO on the XO3 (?) board of TentLabs, which enhances the SPDIF as well.
Tentlabs also has separate power supplies for it, but also look after their low noise stabilisers which could replace the ordinary one(s).
Re: Re: Re: Skipping the PLL-VCXO
I cannot find it.
Well my transport XO is 16.xxx Mhz, so I have to opt for a VCXO.
PA0SU said:
I cannot find it.
PA0SU said:
Well my transport XO is 16.xxx Mhz, so I have to opt for a VCXO.
Re: my opinion to jitter
contains an error. The text should be:
4. The jitter on the outputs of the receiver are about 100 ps with a good receiver and could very well be 500 ps or more with a bad receiver (Yamaha). So connecting the CLOCK-output (MCK, 256.fs) of it directly to the dig.fi (XTI) is no option.
Of cource the DATA (SDATA ==> DI/INF2N) and the bitCLOCK (SCK ==> BCKI) should be connected. Reclocking also here is a waist, because the dig.fi degrades them to a 50 ps......
All the mentioned in and output names count for the combination CS8412, SM5842/7, which I could recommend ........
contains an error. The text should be:
4. The jitter on the outputs of the receiver are about 100 ps with a good receiver and could very well be 500 ps or more with a bad receiver (Yamaha). So connecting the CLOCK-output (MCK, 256.fs) of it directly to the dig.fi (XTI) is no option.
Of cource the DATA (SDATA ==> DI/INF2N) and the bitCLOCK (SCK ==> BCKI) should be connected. Reclocking also here is a waist, because the dig.fi degrades them to a 50 ps......
All the mentioned in and output names count for the combination CS8412, SM5842/7, which I could recommend ........
Re: Re: Re: Re: Skipping the PLL-VCXO
Does this mean that there is no 'extra PLL-VCXO' in the Muse? On top of the VCXO-can the freq. should be printed.
Telstar said:
Does this mean that there is no 'extra PLL-VCXO' in the Muse? On top of the VCXO-can the freq. should be printed.
Ok this is my "sensible" reply.... 
The schematic I've posted to THIS thread uses the PIC-DAC-VCXO loop as a primary loop after CS8412. I choose to remove the receiver PLL/VCO from the picture as far as possible.
The "jitter free" mode of the SM5842 creates a buffer of +/- 3/8*LRCI. This means the VCXO clock can drift within a range of +/-24clock cycles against the incoming data without effecting the operation of the SM5842. I'm being a little conservative and trying to keep the drift controlled within about half this range. Once the PLL is locked and shifts to "loose" loop settings I'm getting an minimum of 6 seconds between DAC updates which translates to a loop filter frequency of 0.17hz, and usually lower. There is no quick reaction, and the "drift" against the SPDIF clock helps to further isolate the VCXO from the incoming jitter.
This is exactly what is achieved using the PIC-DAC-VCXO loop - the VCXO runs with infrequent, small adjustments allowing the output clock to be as stable as possible. Reclocking using the tent schema driven by this stable clock goes a long way to ensuring that data is as stable as possible.
The schematic I've posted to THIS thread uses the PIC-DAC-VCXO loop as a primary loop after CS8412. I choose to remove the receiver PLL/VCO from the picture as far as possible.
The "jitter free" mode of the SM5842 creates a buffer of +/- 3/8*LRCI. This means the VCXO clock can drift within a range of +/-24clock cycles against the incoming data without effecting the operation of the SM5842. I'm being a little conservative and trying to keep the drift controlled within about half this range. Once the PLL is locked and shifts to "loose" loop settings I'm getting an minimum of 6 seconds between DAC updates which translates to a loop filter frequency of 0.17hz, and usually lower. There is no quick reaction, and the "drift" against the SPDIF clock helps to further isolate the VCXO from the incoming jitter.
This is exactly what is achieved using the PIC-DAC-VCXO loop - the VCXO runs with infrequent, small adjustments allowing the output clock to be as stable as possible. Reclocking using the tent schema driven by this stable clock goes a long way to ensuring that data is as stable as possible.
Thanks Paul,
I've ordered the VCXO from tentlabs. Will be implementing the PLL as per your schematic, but not using a PIC.
I've toyed with the idea of buying a cheap 11.xxx MHz cd player but they're not that easy to get hold of and in many instances the lasers are probably near the end of life as well.
Besides, my Theta DATA III is an exceptionally good transport, up there with the Levinson 30.6's of the world. Just a pity it's running at 16.xxxMHz.
I've also now used the DIR9001 as the DIR and it does seem to be better than the 8412, but it's not night and day. More low level details present and better seperation of instruments.
I've ordered the VCXO from tentlabs. Will be implementing the PLL as per your schematic, but not using a PIC.
I've toyed with the idea of buying a cheap 11.xxx MHz cd player but they're not that easy to get hold of and in many instances the lasers are probably near the end of life as well.
Besides, my Theta DATA III is an exceptionally good transport, up there with the Levinson 30.6's of the world. Just a pity it's running at 16.xxxMHz.
I've also now used the DIR9001 as the DIR and it does seem to be better than the 8412, but it's not night and day. More low level details present and better seperation of instruments.
The D1 vcxo/pll uses the CS8412/4 fsync output. It would a minor change to work with dir9001 but I think this misses one of the "details" of the Pass circuit.
This is from a 7-year old post by wildmonkeysects:
QUOTE
One can "ignore" [ well almost, there will be a _small_ amount of jitter feedthrough between two oscillators sharing the same ground plane, but not enough to cause injection locking in this case ] the mclk generated by the 84xx DIR when placing the new master clock and register/reclocker at the DAC.
The new master clock should be whatever the transport requires, probably 384 fs, maybe 256 fs. If 256 fs, you should see the "ignored" mclk pin of the 8412 in synch with the "new master".
If 384 fs, the "ignored" mclk pin of the 8412 will be at 2/3 freq, but in synck, ie not wandering; and there should be sufficient setup and hold times avail at the reclocker/register next to the DAC. If not, invert the polarity of the new master clock at the transport to shift a half clock cycle.
It's a mixed bag, genlocking, or master/slave clocking is more elegant, but more complex...
END QUOTE
To see the rest of the comment:
http://www.audioasylum.com/audio/tweaks/messages/30411.html
Any comments on this? it would be a nice way to avoid having to buy a 11.xxxx cdp....
QUOTE
One can "ignore" [ well almost, there will be a _small_ amount of jitter feedthrough between two oscillators sharing the same ground plane, but not enough to cause injection locking in this case ] the mclk generated by the 84xx DIR when placing the new master clock and register/reclocker at the DAC.
The new master clock should be whatever the transport requires, probably 384 fs, maybe 256 fs. If 256 fs, you should see the "ignored" mclk pin of the 8412 in synch with the "new master".
If 384 fs, the "ignored" mclk pin of the 8412 will be at 2/3 freq, but in synck, ie not wandering; and there should be sufficient setup and hold times avail at the reclocker/register next to the DAC. If not, invert the polarity of the new master clock at the transport to shift a half clock cycle.
It's a mixed bag, genlocking, or master/slave clocking is more elegant, but more complex...
END QUOTE
To see the rest of the comment:
http://www.audioasylum.com/audio/tweaks/messages/30411.html
Any comments on this? it would be a nice way to avoid having to buy a 11.xxxx cdp....
Dr.H said:
How? With a PLL?
I do not understand the details (and the English).
If I understand it well, a masterclock at 256.fs (could only be an XO) has been put in the DAC. OK.
If the transport-freq. is at 384.fs. This oscillator should be tuned so that the MCK of the CS8412 meets the frequency and phase of the master.
So a PLL is needed to generate the tuning voltage for the oscillator in the transport, which must be a VC(X)O.
This tuning voltage should be transported from the DAC to the transport!!!
If so, the last point is very unlikely because of the unwanted added noise to the tuning voltage.
Still the SPDIF from the transport should be enhanced (see my posting # 105).
Is it not more simple to build a low noise master XO at 384.fs into the transport (with an SPDIF enhancer) and build a digital circuit which transforms the 386.fs to 256.fs (= 2/3) which should be transported to the DAC? Or is this a too simple solution from the brains of an analog engineer?
BTW. What is a "cpd" ?
BTW. The bla, bla (in the references) about reflections in the SPDIF-cable between transport and DAC is of minor importance: the length of such an "interlink" will be about 1/100 of the wavelength of the base freq.
BTW. The 'Kwak Clock' Elzo Kwak sells as a master clock is very noisy. It measures jitter figures of 100 ps and more.... Absolutily unusable!!!
Herb,
guess who said this:
"reflections caused by higher frequency components affect the lower ones, including the SPDIF signal (timing)"
cheers
Paul
guess who said this:
"reflections caused by higher frequency components affect the lower ones, including the SPDIF signal (timing)"
cheers
Paul
spzzzzkt said:
Firts of all I have doubts with people who are praisen as a professor and/or chairman of so and so or.... etc. Just let them do their statement.
From the article:
Quote
So, how does this affect the jitter? When the first reflection comes back to the DAC, if the transition already in process at the receiver has not completed, the reflection voltage will superimpose itself on the transition voltage, causing the transition to shift in time. The DAC will sample the transition in this time-shifted state and there you have jitter.
Unquote
1. If the signal should be delayed by reflections, this delay will be constant, so there is no contribution to jitter.
Moreover:
2. Reflections do not shift a signal in time! It only will be distorted.
3. A reflection does not effect the edges of the SPDIF. With a 30 cm long cable, the time is about 1 ns. The signal impulses are in the order of 100 ns.
3. Also in bad situations, reflections are less than 20%, so the distortion will be limited.
4. If the SPDIF-source (in the transport) has been matched to 75 or 50 ohm (depending on the cable in use) there will be only one reflection if the cable has been badly matched in the DAC.
5. One should use an SPDIF-enhancer in the transport (to eliminate all audio cross over on it) which will be perfectly matched (at least the one of TentLabs).
There are many other remarks to make on the article. Losses in the cable should introduce jitter. HOW????
I do not know what kind of cable Nugent is thinking about, but the most bad cable will give a loss of less than 6 dB over a length of 100 meter with a frequency of, say, 10 MHz.
Etc. etc. etc. ........