Thanks IJ, sounds like one can avoid the secondary PLL then!
I will certainly try, but just need to find out why the D1V3 does not work with an independent 11.xxx MHz clock on XTI.
Hopefully Paul or Herb can shed some light on this.
I will certainly try, but just need to find out why the D1V3 does not work with an independent 11.xxx MHz clock on XTI.
Hopefully Paul or Herb can shed some light on this.
Ryan,
It cannot work, not only with the D1V3 but with any dac.
At one side, there is the source, generating data at it's own local clock's pace. You put an independent external clock into the dac, and expect it to have the exact same speed like the one in the mech?
Obviously they are not synchronized. They are close, but not the same.
And the D1V3 will work in a way that it will produce sound for a short interval, then will run out of synch, and will re-synch again and again.
When re-synching, each digital filter behaves differently, mute or produce a click.
It's really annoying and it's what one could call "not working at all".
No way out if not an external PLL. Or the Herb's configuration.
Ciao, George
It cannot work, not only with the D1V3 but with any dac.
At one side, there is the source, generating data at it's own local clock's pace. You put an independent external clock into the dac, and expect it to have the exact same speed like the one in the mech?
Obviously they are not synchronized. They are close, but not the same.
And the D1V3 will work in a way that it will produce sound for a short interval, then will run out of synch, and will re-synch again and again.
When re-synching, each digital filter behaves differently, mute or produce a click.
It's really annoying and it's what one could call "not working at all".
No way out if not an external PLL. Or the Herb's configuration.
Ciao, George
Hi George,
Thanks for the useful info. Whydoes the SM5842 sheet then say that the XTI pin can accept an external clock? Must this be a clock generated by a secondary PLL? 😕 😕
It sounds like Herb's approach is the way to go then.
Would be very keen to try as it seems so simple:
Run transport internal clock signal to BNC output on transport.
Feed via cable to BNC input on DAC.
Disconnect CS8412 MCK output from SM5842 XTI
Connect BNC input on DAC to XTI.
And hopefully there is sweet music...😎
What suprises me is that Herb feels that this approach is even better than the considerably more involved (at least for me) secondary PLL approach.
Thanks again.
Ryan
Thanks for the useful info. Whydoes the SM5842 sheet then say that the XTI pin can accept an external clock? Must this be a clock generated by a secondary PLL? 😕 😕
It sounds like Herb's approach is the way to go then.
Would be very keen to try as it seems so simple:
Run transport internal clock signal to BNC output on transport.
Feed via cable to BNC input on DAC.
Disconnect CS8412 MCK output from SM5842 XTI
Connect BNC input on DAC to XTI.
And hopefully there is sweet music...😎
What suprises me is that Herb feels that this approach is even better than the considerably more involved (at least for me) secondary PLL approach.
Thanks again.
Ryan
Dr.H said:
Hi Ryan,
Basically yes, but you are assuming that the internal clock signal of the transport is good enough. This might well not be so!
Tent XO3.2 is surely the more reliable part to consider. Very short before "leaving" the unit, the signal is re-clocked on the XO3.2 itself, so you know what you get: a separate clean clock.
AND: the SPDIF itself (even if "only" for the DATA alone) is better (I am NOT being employed by Tent - it is just that the product is great).
BTW, if you don't use the receiver for clock recovery, then the 2nd PLL is indeed not needed. May Be, you will have to experiment a bit then with the length of the 2 bnc cables (both 75Ohm); each of them will have some influence on the sound anyhow…
Greetings,
IJ.
Dr.H said:
Ryan,
This STILL violates the basic timing requirements of the PCM63P. You'll still get clipping on the MSB for the reasons described previously. The "improvement" your hearing is just higher output levels.
best
Paul
Ryan,
For the dac to operate correctly the data and clock must be synchronised. If you simply hook up a timing source to the CS8412 or SM5842 without reference to the timing of the data stream coming from the transport the system doesn't work correctly.
If you are going to mess with the timing by reclocking and adding in logic you really need to pay careful attention to the timing requirements of the individual chips and the system as a whole.
best
Paul
For the dac to operate correctly the data and clock must be synchronised. If you simply hook up a timing source to the CS8412 or SM5842 without reference to the timing of the data stream coming from the transport the system doesn't work correctly.
If you are going to mess with the timing by reclocking and adding in logic you really need to pay careful attention to the timing requirements of the individual chips and the system as a whole.
best
Paul
Dr.H said:
The same problem. It is a free running clock that is not synchronized with the incoming data. The result is that the SM5842 continuously re-synchs, giving rapid clicking on the output.
Dr.H said:
Herb's approach is technically better if you are prepared to accept the compromise that you locked into using the modified transport-dac combination. Integrating everything into a CD player is a even better approach, as I'm sure Herb will agree.
As IJ says, it is simple if you use a Tent XO3.2 which is equipped with a clock output designed for this purpose. If you intend to diy you'll find that it isn't quite as straight forward.
Very interesting thread!
I'm thinking to finally mod my Muse model2 dac, which has two pcm63k chips.
I already have a Tent XO3 (w/ supply) ready to be put into my VRDS transport, but I waited because I was thinking to replace the DAC altogether.
First question, is the XO3 suitable? Or I need the v3.2?
Second question, anybody has the scheme of my Muse? I'm trying to ask to the manifacturer.
I'm thinking to finally mod my Muse model2 dac, which has two pcm63k chips.
I already have a Tent XO3 (w/ supply) ready to be put into my VRDS transport, but I waited because I was thinking to replace the DAC altogether.
First question, is the XO3 suitable? Or I need the v3.2?
Second question, anybody has the scheme of my Muse? I'm trying to ask to the manifacturer.
Skipping the PLL-VCXO
Fixing the XO3 into your transport and use the enhanced SPDIF output from it, will already enhance the audio using your Muse. This is a first step. Do it, even if you use the audio output of the transport!
If you would like to implement my 'CDprincipe4' (I published here several times) the clock freq. in the Muse MUST be the same as in your transport! Look after it.
In case they are not equal you must use a PLL-VCXO in the Muse DAC or buy you a transport with the same freq. as in the Muse (as the Muse is worth it. I do not know it). Here in Eindhoven you could by Philips transports for 30 euro..... Bags of them.
Telstar said:
Fixing the XO3 into your transport and use the enhanced SPDIF output from it, will already enhance the audio using your Muse. This is a first step. Do it, even if you use the audio output of the transport!
If you would like to implement my 'CDprincipe4' (I published here several times) the clock freq. in the Muse MUST be the same as in your transport! Look after it.
In case they are not equal you must use a PLL-VCXO in the Muse DAC or buy you a transport with the same freq. as in the Muse (as the Muse is worth it. I do not know it). Here in Eindhoven you could by Philips transports for 30 euro..... Bags of them.
Thanks for all the input guys. All the feedback below is from a digital newbie, so read it in that context.
I have since removed the 174 and 374 from the DAC. Will have to find a way to reclock LE, data and BCK first. So far, attempts at reclocking all 3 have led to noise (using CK from Sm5842 as clock input for reclocker)...
As for the VCXO PLL: Well, all I have is an XO, and its 11.xxxMHZ, not the 16.xxx thats in the transport.
Is there an easy way to convert this to a VCXO ad if there is would it matter that the frequency is different to the transports?
As for Herb's idea of sending the transport clock to the DAC:
I have a theta Data III transport, which uses a 16.xxx MHz clock. I tried to 3 things:
a. Send the clock to the DAC on a seperate line and at the DAC, the incoming clock goes to the XTI pin of SM5842; Noise on both channels.
b. Take the inverted (74HCU04, pin2) clock and try the same. Same result, noise
c. Re-invert the inverted clock in b and send to DAC. Music (with small amounts of distortion) on one channel, noise on the other.
I think I'll stop these "experiments" for now. Clearly my digital knowledge is not sufficient to accomplish much!
I have since removed the 174 and 374 from the DAC. Will have to find a way to reclock LE, data and BCK first. So far, attempts at reclocking all 3 have led to noise (using CK from Sm5842 as clock input for reclocker)...
As for the VCXO PLL: Well, all I have is an XO, and its 11.xxxMHZ, not the 16.xxx thats in the transport.
Is there an easy way to convert this to a VCXO ad if there is would it matter that the frequency is different to the transports?
As for Herb's idea of sending the transport clock to the DAC:
I have a theta Data III transport, which uses a 16.xxx MHz clock. I tried to 3 things:
a. Send the clock to the DAC on a seperate line and at the DAC, the incoming clock goes to the XTI pin of SM5842; Noise on both channels.
b. Take the inverted (74HCU04, pin2) clock and try the same. Same result, noise
c. Re-invert the inverted clock in b and send to DAC. Music (with small amounts of distortion) on one channel, noise on the other.
I think I'll stop these "experiments" for now. Clearly my digital knowledge is not sufficient to accomplish much!
Re: Skipping the PLL-VCXO
I'll check with Tent the diffs between my verison and the 3.2.
Yes, I think thats what I want to do 🙂
I asked the schematics and I'm waiting for those.
What's the point to get a cheaper transport than my vrds? I do not like the too powerful bass of cdpro units. My muse is worth between 500 and 700 euros in the used market. It has awesome construction, that's why I want to improve it 🙂
PA0SU said:
I'll check with Tent the diffs between my verison and the 3.2.
Yes, I think thats what I want to do 🙂
I asked the schematics and I'm waiting for those.
What's the point to get a cheaper transport than my vrds? I do not like the too powerful bass of cdpro units. My muse is worth between 500 and 700 euros in the used market. It has awesome construction, that's why I want to improve it 🙂
Re: Re: Skipping the PLL-VCXO
I'm NOT talking about the CDpro. BTW I never noticed a 'too powerfull bass' from it. There is no transport mechanism which could influence the sound in this way if you use a low jitter clock, SPDIF enhancement (and reclocking) ....
Ok, OK, stick to the Muse, but if you want to skip the PLL-VCXO (which will give a great enhancement because a VCXO always noises more than a good XO!) you must have a transport with the same clock-freq. In your case 11.xxxx MHz.
I use the plastic box CD624 with a CDM4 in it (with glass lens). It has an empty compartment you could fix into a lot of things....
It looks cheep and has a bad userinterface, but it sounds great because of the neat developped PCB.
Telstar said:
I'm NOT talking about the CDpro. BTW I never noticed a 'too powerfull bass' from it. There is no transport mechanism which could influence the sound in this way if you use a low jitter clock, SPDIF enhancement (and reclocking) ....
Ok, OK, stick to the Muse, but if you want to skip the PLL-VCXO (which will give a great enhancement because a VCXO always noises more than a good XO!) you must have a transport with the same clock-freq. In your case 11.xxxx MHz.
I use the plastic box CD624 with a CDM4 in it (with glass lens). It has an empty compartment you could fix into a lot of things....
It looks cheep and has a bad userinterface, but it sounds great because of the neat developped PCB.
Herb,
1. How do you know the frequency of the DAC?
I am using a a THETA DATA III transport which uses a 16.xxx MHz clock and it works well with the D1V3 DAC developed by Spencer. Paul is using the same DAC. The DAC uses CS8412, Sm5842, 74HC86 and PCM63 chips. There is no local oscillator in the DAC.
2. How would you determine it's operating frequency?
1. How do you know the frequency of the DAC?
I am using a a THETA DATA III transport which uses a 16.xxx MHz clock and it works well with the D1V3 DAC developed by Spencer. Paul is using the same DAC. The DAC uses CS8412, Sm5842, 74HC86 and PCM63 chips. There is no local oscillator in the DAC.
2. How would you determine it's operating frequency?
Ryan,
The receiver chip - CS8412 in this case - recovers the timing information from the SPDIF signal and locks it's internal PLL/VCO to the incoming clock. The CS8412 then outputs 256*Fs (fs=44.1khz for cd reproduction) on SCK (pin 11). 256*fs=11.2896mhz. This drives the rest of the DAC. Most DAC's will operate at a multiple of 44.1khz or 48khz depending on the source sampling rate - ie CD, DVD etc.
So there is no standalone oscillator, just the Voltage Controlled Oscillator embedded in the CS8412. The main problem with the CS8412 (and most other receivers for that matter) is that the PLL has liitle jitter attenuation below 10khz. The datasheet shows it has a small amount of BOOST at 10khz, and only 5dB of attenuation at 20Khz. The filter corner frequency of 10khz can be lowered by tweaking the external filter components attached to the CS8412 - connected between FILT (pin 20) and AGND - as done by Wildmonkeysects and in the TentDAC.
The effect of this low attenuation is that jitter is coupled from the SPDIF signal to the VCO through the PLL. I think it's important to note when you look at a spdif reciever spec sheet the quoted jitter figure is INTRINSIC jitter only. That is the jitter contribution of the receiver ALONE without consideration of jitter coupled from the incoming SPDIF signal.
So the options you have are - use a cd-player and bypass the whole problem, use i2s and reduce the problem, follow the Herb/TentLink separate clock connection path, or retain SPDIF and use VCXO/PLL's to supply a cleaner clock than that output by the receiver chip.
cheers
Paul
The receiver chip - CS8412 in this case - recovers the timing information from the SPDIF signal and locks it's internal PLL/VCO to the incoming clock. The CS8412 then outputs 256*Fs (fs=44.1khz for cd reproduction) on SCK (pin 11). 256*fs=11.2896mhz. This drives the rest of the DAC. Most DAC's will operate at a multiple of 44.1khz or 48khz depending on the source sampling rate - ie CD, DVD etc.
So there is no standalone oscillator, just the Voltage Controlled Oscillator embedded in the CS8412. The main problem with the CS8412 (and most other receivers for that matter) is that the PLL has liitle jitter attenuation below 10khz. The datasheet shows it has a small amount of BOOST at 10khz, and only 5dB of attenuation at 20Khz. The filter corner frequency of 10khz can be lowered by tweaking the external filter components attached to the CS8412 - connected between FILT (pin 20) and AGND - as done by Wildmonkeysects and in the TentDAC.
The effect of this low attenuation is that jitter is coupled from the SPDIF signal to the VCO through the PLL. I think it's important to note when you look at a spdif reciever spec sheet the quoted jitter figure is INTRINSIC jitter only. That is the jitter contribution of the receiver ALONE without consideration of jitter coupled from the incoming SPDIF signal.
So the options you have are - use a cd-player and bypass the whole problem, use i2s and reduce the problem, follow the Herb/TentLink separate clock connection path, or retain SPDIF and use VCXO/PLL's to supply a cleaner clock than that output by the receiver chip.
cheers
Paul
I've been messing with the mod, as I'm not entirely happy with the results. After a week of listening to the orignal mod I had a real sense that the highs were rolled off and just not quite right. I'm having to listen a few notches louder on the volume to get back to previous listening levels.
Anyway in the interest of "science" I've altered the mod to "AND" WCKO and DG which means LE goes high on the 16th bit and low 2 clock cycles earlier than standard. This means the possible requirement of LE being high for one BCLK is met, and the extra (potential) settling time is still in place.
The initial results are that highs are a bit more defined and open, but the volume level is still down. {carp about volume drop deleted}
I'll really need to go back to listen to the normal config to make sure I'm not imagining things.
Anyway in the interest of "science" I've altered the mod to "AND" WCKO and DG which means LE goes high on the 16th bit and low 2 clock cycles earlier than standard. This means the possible requirement of LE being high for one BCLK is met, and the extra (potential) settling time is still in place.
The initial results are that highs are a bit more defined and open, but the volume level is still down. {carp about volume drop deleted}
I'll really need to go back to listen to the normal config to make sure I'm not imagining things.
Paul,
Thanks for the useful info, I've learnt alot from these posts. A couple of questions:
1. What does the transport clock (in my case 16.xxx MHz) have to do with the clock (11.xxx MHz) that the internal PLL/VCO creates?
2. I guess the fact that my transport is using 16.xxx MHz means I cannot simply feed the transport clock to the DAC?
3. If however I was using a transport based on an 11.xx MHz clock, I'd be able to try this idea of sending the transport clock to the DAC?
4. You mentioned that the VCXO has to be low jitter to work in a secondary PLL. Would Guido's product be the simplest approach to this or is there a way to get my 11.xxx XO (also from Tent) to behave like a VCXO? What about merely buying a generic 11.xxx MHz VCXO from an electronics vendor? I know the jitter will be higher than Tent's product, but would it not be better going down this route than using the internal PLL-VCO on the cs8412?
5. Finally, is the secondary VCXO worth implementing from an audio perspective? What happens to the sound? Lower noise floor, air on highs, tighter bass, better soundstage? Meaningful difference or a 1% move in the right direction.
As always, thanks for your input!
Ryan
Thanks for the useful info, I've learnt alot from these posts. A couple of questions:
1. What does the transport clock (in my case 16.xxx MHz) have to do with the clock (11.xxx MHz) that the internal PLL/VCO creates?
2. I guess the fact that my transport is using 16.xxx MHz means I cannot simply feed the transport clock to the DAC?
3. If however I was using a transport based on an 11.xx MHz clock, I'd be able to try this idea of sending the transport clock to the DAC?
4. You mentioned that the VCXO has to be low jitter to work in a secondary PLL. Would Guido's product be the simplest approach to this or is there a way to get my 11.xxx XO (also from Tent) to behave like a VCXO? What about merely buying a generic 11.xxx MHz VCXO from an electronics vendor? I know the jitter will be higher than Tent's product, but would it not be better going down this route than using the internal PLL-VCO on the cs8412?
5. Finally, is the secondary VCXO worth implementing from an audio perspective? What happens to the sound? Lower noise floor, air on highs, tighter bass, better soundstage? Meaningful difference or a 1% move in the right direction.
As always, thanks for your input!
Ryan
Nothing!! It is simply the frequency the transport clocked circuits run at. The data format sent via spdif connection encodes the 44.1khz sampling frequency which the receiver extracts and generates a master clock from. It's basically just a higher multiple of the cd sampling rate. 384*fs = 16.9344mhz. I'm using at TEAC VRDS T-1 which uses a Sony CXD2500AQ chip to control the bulk of the transport functionality - servos, error correction, digital output etc, and this runs from either 16.9344mhz or 33.8688mhz. So component choice plays a large part in what the internal clock rate is chosen.
No. You'd have to divide down the transport clock, and dividing by 3 while retaining a 50% duty cycle requires a stack of logic, so your clock quality goes down the tubes.
Yes.
Unfortunately 11.2896mhz isn't a common industrial frequency, so they aren't that easy to find. They tend to be special order items, subject to Minimum Order Quantities. This is one of the reasons that Tent Labs is a popular source - they are one of the few avenues available to a DIYer looking for a single part. Ecliptek have a MOQ of 1000 parts for example.
Wellllllllll!!!! I hope so 😉 I've spent months and months messing about with this thing!
My original take on the D1V3 was that it was a pretty nice sounding DAC. It sounds pretty lush, wide sound staging, etc etc. Nice and HiFi.
The first step of building a clone of D1 PLL with mods to allow using the Tent VCXO instead of the original Fujitsu really opened my eyes. That resulted in everything becoming more focus - the lushness was replaced by more precise imaging and tighter, slightly leaner bass. I'd described the difference to IJ as the D1V3 having a velvet wrapped sound, it's luxurious but there's a fine fuzz that obscures the details. Just reclocking the SM5842 with the VCXO strips off layers of that "fuzz".
The current level of reclocking - PIC controlled PLL (which has a sub 1hz effective filter frequency when locked) and the TentDAC reclocking schema - seriously refines the gains of just using the D1 PLL to reclock the SM5842. The bass is more extended and solid, but retains the tightness. I listen to quite a bit of stuff by bassist/producer Bill Laswell and I now hear detail and textures in his playing that I hadn't noticed before. I was listening to Eric Dolphy's "Out To Lunch" earlier and the imaging is sharp - you can hear the positioning of strikes on different parts of a cymbal quite distinctly for example. The overall balance of the sound has improved also. Piggybacking all this off the back of the D1V3 is really less than optimal, and having spdif reciever, digital filter, clocking circuits and dacs all on one board should bring further improvements.
Thanks Paul,
Looks like I'll be hunting for a 11.xxx MHz cd player as first prize. At least that should provide a sense of the improvments that are possible. An d I assume that I then fit that with a Tentlabs clock, it should be even better.
Else, I'll be implementing the PLL you posted (the non-PIC one...).
Thanks again.
Looks like I'll be hunting for a 11.xxx MHz cd player as first prize. At least that should provide a sense of the improvments that are possible. An d I assume that I then fit that with a Tentlabs clock, it should be even better.
Else, I'll be implementing the PLL you posted (the non-PIC one...).
Thanks again.
Sounds as good place start as any!!
If you have the Tent XO you should investigate something like the PFM Flea to power it.
http://www.acoustica.org.uk/t/naim/35clockreg.html
If you have the Tent XO you should investigate something like the PFM Flea to power it.
http://www.acoustica.org.uk/t/naim/35clockreg.html