Regal,
Very valid question. I don't have the D1V3, I have a Tent dac, with tube output, which produces the same[?] -60dB second harmonic, just measured it.
Here I have replaced not the DIR, but the original analog PLL scheme developed by Guido Tent. That original setup works flawless, has a very low corner frequency ~at 10-20Hz, and gave a smooth shiny sound. The phase noise on the VCXO is uncomparable to any of the DIR units mentioned here.
My eternal [slight] problem with this setup was it's bass performance - why, it's hard to describe.. It's rather quality, not quantity question.
With this digital PLL solution the bass has changed significantly. Gained foundation. Why, don't ask me..
One possible explanation to your original question: The tube / jfet distortion is harmonically correlated with the signal. If You look at the spectra, you see the signal and the harmonic lines. Nothing in between, and a clean deep noise floor. Your ear produces this all the time, up to the 10-30 %.. Also all electromechanical transducers are doing the same, that is, You NEVER get real 0.1 % distortion arriving at your ears.
The SPDIF connection introduces NON harmonic data correlated distortion - first, the signal will have that "skirt" around it, that is, modulated sidebands, and they can be much higher than -110dBc. Then, the noise floor will be raised, and changing with the signal, it gets "modulated". Third, SPDIF interface distortion introduces a spray of high frequency spuries, that is, non-harmonically correlated low level high frequency tones, which are changing with data..
Cleaning it up, that is the problem..
Very valid question. I don't have the D1V3, I have a Tent dac, with tube output, which produces the same[?] -60dB second harmonic, just measured it.
Here I have replaced not the DIR, but the original analog PLL scheme developed by Guido Tent. That original setup works flawless, has a very low corner frequency ~at 10-20Hz, and gave a smooth shiny sound. The phase noise on the VCXO is uncomparable to any of the DIR units mentioned here.
My eternal [slight] problem with this setup was it's bass performance - why, it's hard to describe.. It's rather quality, not quantity question.
With this digital PLL solution the bass has changed significantly. Gained foundation. Why, don't ask me..
One possible explanation to your original question: The tube / jfet distortion is harmonically correlated with the signal. If You look at the spectra, you see the signal and the harmonic lines. Nothing in between, and a clean deep noise floor. Your ear produces this all the time, up to the 10-30 %.. Also all electromechanical transducers are doing the same, that is, You NEVER get real 0.1 % distortion arriving at your ears.
The SPDIF connection introduces NON harmonic data correlated distortion - first, the signal will have that "skirt" around it, that is, modulated sidebands, and they can be much higher than -110dBc. Then, the noise floor will be raised, and changing with the signal, it gets "modulated". Third, SPDIF interface distortion introduces a spray of high frequency spuries, that is, non-harmonically correlated low level high frequency tones, which are changing with data..
Cleaning it up, that is the problem..
Joseph, I added a tube stage in place of the D1 I/V on half of the D1V3. The tube stage is close to the Tent version only 6n6P and CCS. Too bad we can't compare these similiar DAC's. I would be interested in trying your digital PLL on the D1V3.
Finney,
Check page 26 of the DIR9001 and you'll note that one of the differences from the DIR1703 is that the DIR9001 DOES NOT use SpACT. In fact the data sheet states that the DIR9001 uses a "Conventional PLL".
Which is precisely why the D1 used FSYNC to drive the VCXO/PLL. On the CS8412/4 FSYNC is generated DIRECTLY from the incoming data stream, and delivers a clock that crystal claim is "as spectrally pure as the digital audio source clock for moderate length transmission lines". This means no (or minimal) jitter added to what is coming off the SPDIF cable and makes FSYNC ideal for driving the PLL comparator. I see nothing comparable available on the DIR9001. Page 7 of the CS8412 datasheet has the rather brief details.
I've had a bad head cold for the past couple of days which has not been conducive to troubleshooting. I've made some progress, so maybe over the next day or two I'll get this damn thing locking.
Paul
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)
Check page 26 of the DIR9001 and you'll note that one of the differences from the DIR1703 is that the DIR9001 DOES NOT use SpACT. In fact the data sheet states that the DIR9001 uses a "Conventional PLL".
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.
Which is precisely why the D1 used FSYNC to drive the VCXO/PLL. On the CS8412/4 FSYNC is generated DIRECTLY from the incoming data stream, and delivers a clock that crystal claim is "as spectrally pure as the digital audio source clock for moderate length transmission lines". This means no (or minimal) jitter added to what is coming off the SPDIF cable and makes FSYNC ideal for driving the PLL comparator. I see nothing comparable available on the DIR9001. Page 7 of the CS8412 datasheet has the rather brief details.
I've had a bad head cold for the past couple of days which has not been conducive to troubleshooting. I've made some progress, so maybe over the next day or two I'll get this damn thing locking.
Paul
kevinkr said:Paosu, the link to your website is broken.
Yes. I know. Too many Mb's per day have been downloaded. Be patient. It could be that this is a kind of attack of someone who does not like me.........
Joseph K said:Finney,
Do You refer to me? If yes, then I will be forced to take this seriously, and act up consequently... These are false accusations in public. Show me only one link which points to me, selling something!!
George
Nope, not you. Sorry for the confusion.

Originally posted by Joseph K
Exactly this is why a PIC [that is, microcontroller] comes in handy. One can CHANGE the loop characteristics on the fly, lock fast, and once in lock, change to a very low corner frequency. At this moment I don't touch absolutely anything for 5-10-20 seconds, then adjust one step up or down, as needed.
And don't tell me that it's impossible, because exactly this is what happening in any ASRC; and this is what the SPACT patent is about! [changing loop parameters on the fly]
I think you have totally missed my point. Ok, you admit there's a corner frequency left, right? Is it drifting? Can you conveniently ignore it? This phase noise isnt a big deal to you? This jitter doesnt bother you? Are you sure 100% of the time, your PLL's somewhat inert moving will actually remove the input jitter? Or simply make it worse?
The basic principle is very simple. PLL can easily lock in the input signal then *drift* with it. This is exactly what a PLL is supposed to do. If the input has jitter, the PLL jitters, too. FIFO is a high Q device, ASRC is a high Q device but PLL is not! It's the small buffer in the DF which gives you the Q. Yet this buffer does not cover your PLL clock and this jittered clock is used to drive the DAC. This is the main problem! How can you be so sure the PLL clock has less jitter? Eventually you are just duplicating what DIR9001 is supposed to do.
Now whether the small buffer in DF can give you enough Q, that will be for open dispute. You feel it's enough for you yet I have seen plenty of cases that it's purely useless. This is also why digital lens failed. Dont even mention the signals no PLL can lock up consistently.
In the meantime, there is a DAC driving the VCXO, where one can have the parameters under control:
Can use a low noise reference.
Can keep impedances low [in analog PLL-s with a low corner frequency, the impedances must be high - means excess noise]
Can low pass filter the control DAC output extensively.
Again, the question is, whether your PLL follows the input? Yes, you can reduce the noise inherited in the loop but this just reduces the jitter created by the loop itself. It has nothing to do with the jitter coming along with the input signal which you try to lock, right? You have to move along the input, right?
And a properly built PIC VCXO is another major solution, only much cheaper..
A good input with DIR9001 with ASRC will work much better than it. That's the answer. Sure, you pay the price for the FIR. Still, the DF has a FIR, too, anyway.
BTW, DIR9001 actually has done a very good job with power supply internally. The 50ps jitter spec does not come as free lunch, OK?
QSerraTico_Tico said:One can use Elso's I2SDirect scheme if you are willing to drill some holes. It completely omits the SPDIF interface. Shown is for NON-OS DAC.
No need for FIFOs, PLLs etc.
http://www.diyaudio.com/forums/showthread.php?postid=1355196#post1355196
The main diffculty with I2S is the transmission. Not an easy job. On the receive side, you will first do something to put the clock back into good shape then use it to reclock other signals to have everything in phase.
spzzzzkt said:Check page 26 of the DIR9001 and you'll note that one of the differences from the DIR1703 is that the DIR9001 DOES NOT use SpACT. In fact the data sheet states that the DIR9001 uses a "Conventional PLL".
Ok, gossip time! 😀
We are doing a project for TI's HPA (high performance analog) division. From the grape vine I heard that there were certain problems around DIR1703 and the production cost was high. They had to modify it a bit then brought out DIR9001. Basically the lock loop is still pretty similar. The SpACT is a silly marketing slogan. People know the technology know it's nothing new. For the rest, it's meaningless. Eventually they just removed it from the datasheet.
Which is precisely why the D1 used FSYNC to drive the VCXO/PLL. On the CS8412/4 FSYNC is generated DIRECTLY from the incoming data stream, and delivers a clock that crystal claim is "as spectrally pure as the digital audio source clock for moderate length transmission lines". This means no (or minimal) jitter added to what is coming off the SPDIF cable and makes FSYNC ideal for driving the PLL comparator. I see nothing comparable available on the DIR9001. Page 7 of the CS8412 datasheet has the rather brief details.
The main problem with 8412/8414 is the limitation of silicon technology at its time. Mixed signal stuff was very hard to do back then. This is why you see that it has to take extra signals in. Even with the external filter, you can have tons of game to play.
This is also why you can see so many different reclocking ideas around 8412. The truth is nobody work would 100% of the time. Most of them are just bogus. If the DIR were bad, it IS bad.
I've had a bad head cold for the past couple of days which has not been conducive to troubleshooting. I've made some progress, so maybe over the next day or two I'll get this damn thing locking.
Nice to know you are better now. Well, bascially you can just tighten up the loop by making the PIC do smarter stepping or tuning the filter. But if you tightening it too much, it will just be a input jitter follower; too loose, you will have the jumpy issue again. The bottom line is you will not gain much and mostly just make it all worse. You will know what I am saying when you are there.
The basic principle is very simple. PLL can easily lock in the input signal then *drift* with it. This is exactly what a PLL is supposed to do.
I think the above statement make sense to me!
I think the above statement make sense to me!
PA0SU said:
Yes. I know. Too many Mb's per day have been downloaded. Be patient. It could be that this is a kind of attack of someone who does not like me.........
Congradulation, you may be qualified to earn advertisment fund when you get certain hit.
Also I think I am sure your service provider can find out where is the hit come from and report to the FBI... it could be a new virus attack! More people will like you if you can disclose the virus here as soon as possible.
The World Turn'd Upside Down
Finney,
So let me see if I got this straight:
a) If you make an apparent error in your posts it is actually "insider" information gleaned from conversations with Senior Engineers at Major Corporations
b) The information in data-sheets is usually incorrect: features that are documented are either completely different to what is implemented in silicon or if the features are similar they don't work correctly or only part of the time for some people. Implementations described in the Datasheet are actually "hacks". The only way to obtain the correct information is by the means described in point a).
That's a pretty amazing insight into the machinations of the Electronics Industry. I guess I best buy a kit from your friends, and save myself a lot of grief.
thanks for sharing your wisdom.
Paul
Finney,
So let me see if I got this straight:
a) If you make an apparent error in your posts it is actually "insider" information gleaned from conversations with Senior Engineers at Major Corporations
b) The information in data-sheets is usually incorrect: features that are documented are either completely different to what is implemented in silicon or if the features are similar they don't work correctly or only part of the time for some people. Implementations described in the Datasheet are actually "hacks". The only way to obtain the correct information is by the means described in point a).
That's a pretty amazing insight into the machinations of the Electronics Industry. I guess I best buy a kit from your friends, and save myself a lot of grief.
thanks for sharing your wisdom.
Paul
More gossip, about the good sound of DAT machine Sony PCM7010.
I have been collecting DAT machines for years, most of them I bought broken (hence cheap) and had to do the fix myself.
In a DAT machine, the digital datum are read by playback heads sitting inside a fast spinning drum. The ultimate bit clock is in reality decided by the rotation speed of the drum. The high spinning speed gives the drum a high moving mass, the high moving mass goes to smooth rotation speed, and in turn, the read out bit data has relatively low jitter. The XO used down the line may not be good, still, the original low jitter data has provide a solid fundation for the good sound.
Another proof that it's really the source which matters the most. I am not saying clock isnt important. It's just the source outweights everything.
All these DAC talks, it's funny that I seldom listen to them. I am playing with this most of the time:
Now that's what I call real low jitter!
I have been collecting DAT machines for years, most of them I bought broken (hence cheap) and had to do the fix myself.
In a DAT machine, the digital datum are read by playback heads sitting inside a fast spinning drum. The ultimate bit clock is in reality decided by the rotation speed of the drum. The high spinning speed gives the drum a high moving mass, the high moving mass goes to smooth rotation speed, and in turn, the read out bit data has relatively low jitter. The XO used down the line may not be good, still, the original low jitter data has provide a solid fundation for the good sound.
Another proof that it's really the source which matters the most. I am not saying clock isnt important. It's just the source outweights everything.
All these DAC talks, it's funny that I seldom listen to them. I am playing with this most of the time:
An externally hosted image should be here but it was not working when we last tested it.
Now that's what I call real low jitter!
Finney,
As regards the bad words, it's Ok with me and I would like to ask pardon from my side as well, I have exaggerated. You don't sell those things and instead what You [and Spencer] produced and sell here is a great thing which bears all my respect. {D1V3}
Then - hm.. Let's try to disentangle the knot from this side:
Ok. So we agree that in a PLL the input phase noise is:
~remains intact below the loop corner frequency [the loop output follows the input signal - that is, the long term thermal drifts]
at around the corner freq, both the input signal's phase noise is there and the VCXO phase noise is there, and it might be even peaking - depends on filter characteristics
~ a decade above the corner frequency, the input phase noise is OPRESSED, and the remaining phase noise is that of the VCXO - all effects included [the list I made, about references and all]
NOW. If we have, lets say, .01Hz corner frequency, a DECADE above means .1Hz.
So at & above .1Hz the only thing that remains /counts is the factors listed by me:
a low noise VCXO driven by a low noise reference/ control dac.
My answer is above.
Then. A PLL system consists of: A PFD, VCO, loop filter. this is all what is needed to recreate a clean local clock. Where do you see buffers / buffer size in this equation? So my recreated clock is clean and jitterless, on the contrary to your claim.
The buffer size counts, if one wishes to retrieve an intact data stream on the output. Clearly a longer buffer permits higher amplitude phase shifts between the input / recovered clocks. And what happens if I do not comply to the rule?
I might loose a word every .. hm.. let's say, minute? Have you ever considered the losses what people tolerates in, for example, asynch reclocking?
I would repeat: I don't hear any losses, though my system signals each synch error with a slight click, and I was hunting for them..
Lastly, to reformulate again: Yes, this dig. PLL does not stop the input -"jitter" as you call it though really it's thermal drifts - but rather follows it - chrissake, this is the target function!!
Then anything that would happen more frequently than ~once each 10 second, become suppressed. Is that clean enough?
Ciao, George
As regards the bad words, it's Ok with me and I would like to ask pardon from my side as well, I have exaggerated. You don't sell those things and instead what You [and Spencer] produced and sell here is a great thing which bears all my respect. {D1V3}
Then - hm.. Let's try to disentangle the knot from this side:
Again, the question is, whether your PLL follows the input? Yes, you can reduce the noise inherited in the loop but this just reduces the jitter created by the loop itself. It has nothing to do with the jitter coming along with the input signal which you try to lock, right? You have to move along the input, right?
Ok. So we agree that in a PLL the input phase noise is:
~remains intact below the loop corner frequency [the loop output follows the input signal - that is, the long term thermal drifts]
at around the corner freq, both the input signal's phase noise is there and the VCXO phase noise is there, and it might be even peaking - depends on filter characteristics
~ a decade above the corner frequency, the input phase noise is OPRESSED, and the remaining phase noise is that of the VCXO - all effects included [the list I made, about references and all]
NOW. If we have, lets say, .01Hz corner frequency, a DECADE above means .1Hz.
So at & above .1Hz the only thing that remains /counts is the factors listed by me:
a low noise VCXO driven by a low noise reference/ control dac.
How can you be so sure the PLL clock has less jitter?
My answer is above.
Then. A PLL system consists of: A PFD, VCO, loop filter. this is all what is needed to recreate a clean local clock. Where do you see buffers / buffer size in this equation? So my recreated clock is clean and jitterless, on the contrary to your claim.
The buffer size counts, if one wishes to retrieve an intact data stream on the output. Clearly a longer buffer permits higher amplitude phase shifts between the input / recovered clocks. And what happens if I do not comply to the rule?
I might loose a word every .. hm.. let's say, minute? Have you ever considered the losses what people tolerates in, for example, asynch reclocking?
I would repeat: I don't hear any losses, though my system signals each synch error with a slight click, and I was hunting for them..
Lastly, to reformulate again: Yes, this dig. PLL does not stop the input -"jitter" as you call it though really it's thermal drifts - but rather follows it - chrissake, this is the target function!!
Then anything that would happen more frequently than ~once each 10 second, become suppressed. Is that clean enough?
Ciao, George
Re: The World Turn'd Upside Down
Paul,
There's nothing tricky about it. The datasheet is basically a joined effort between the engineering department and the marketing department. The opening feature description usually has the final touch by the marketing department. What you should look into are the real numbers by the engineers and the application notes. Dont get too serious about the feature part, that's it. People change the terms, describe things in a different way to help sale. That's the marketing people's job.
DIR1703 isnt very successful due to certain problem around it. Marketing people are smart enough to give DIR9001 a fresh new look. I even feel the 50ps claim is bogus.
Sometimes the functional diagram gives you more info yet TI is famous for pretty bad at that. Comparatively, if you look at ADI's datasheet, you will see more infos are revealed.
Personally I like DIR1703 better, BTW.
spzzzzkt said:Finney,
So let me see if I got this straight:
a) If you make an apparent error in your posts it is actually "insider" information gleaned from conversations with Senior Engineers at Major Corporations
b) The information in data-sheets is usually incorrect: features that are documented are either completely different to what is implemented in silicon or if the features are similar they don't work correctly or only part of the time for some people. Implementations described in the Datasheet are actually "hacks". The only way to obtain the correct information is by the means described in point a).
That's a pretty amazing insight into the machinations of the Electronics Industry. I guess I best buy a kit from your friends, and save myself a lot of grief.
thanks for sharing your wisdom.
Paul
Paul,
There's nothing tricky about it. The datasheet is basically a joined effort between the engineering department and the marketing department. The opening feature description usually has the final touch by the marketing department. What you should look into are the real numbers by the engineers and the application notes. Dont get too serious about the feature part, that's it. People change the terms, describe things in a different way to help sale. That's the marketing people's job.
DIR1703 isnt very successful due to certain problem around it. Marketing people are smart enough to give DIR9001 a fresh new look. I even feel the 50ps claim is bogus.
Sometimes the functional diagram gives you more info yet TI is famous for pretty bad at that. Comparatively, if you look at ADI's datasheet, you will see more infos are revealed.
Personally I like DIR1703 better, BTW.
Spencer,
No, the above statement is an [intentional?] obfuscating of the message.
Because PLLs are used for more than one purpose. When the intention is to synchronize, than above statement is valid.
When the intention is to recreate a clean clock, then one uses the PLL as a filter, it's capability of suppressing the incoming phase noise, above it's loop bandwith.
The basic principle is very simple. PLL can easily lock in the input signal then *drift* with it. This is exactly what a PLL is supposed to do.
I think the above statement make sense to me!
No, the above statement is an [intentional?] obfuscating of the message.
Because PLLs are used for more than one purpose. When the intention is to synchronize, than above statement is valid.
When the intention is to recreate a clean clock, then one uses the PLL as a filter, it's capability of suppressing the incoming phase noise, above it's loop bandwith.
Joseph K said:Finney,
As regards the bad words, it's Ok with me and I would like to ask pardon from my side as well, I have exaggerated. You don't sell those things and instead what You [and Spencer] produced and sell here is a great thing which bears all my respect. {D1V3}
No no no. I am not selling D1V3. Spencer showed me the D1V2 then I gave him some suggestions, checked the floorplan, etc. I even had to buy the PCBs from Spencer.
I am not selling anything other than what I dd with my formal job.
My answer is above.
Then. A PLL system consists of: A PFD, VCO, loop filter. this is all what is needed to recreate a clean local clock. Where do you see buffers / buffer size in this equation? So my recreated clock is clean and jitterless, on the contrary to your claim.
The buffer size counts, if one wishes to retrieve an intact data stream on the output. Clearly a longer buffer permits higher amplitude phase shifts between the input / recovered clocks. And what happens if I do not comply to the rule?
I might loose a word every .. hm.. let's say, minute? Have you ever considered the losses what people tolerates in, for example, asynch reclocking?
I would repeat: I don't hear any losses, though my system signals each synch error with a slight click, and I was hunting for them..
You misunderstood my point again. There's always a trade-off. A cleaner loop or a tighter loop. I am trying to say that you are walking on the thin line by loosening the loop a little bit yet still keep the small buffer under control. You claim that this works for you but I am telling you that this is not a good idea. May not work all the time. People at TI had gone through the same thing many runs and runs and I have seen their data, OK? They also want to have a clean clock out of the DIR, OK? You think they do not know all of your tricks? Been there, done that! 🙂
Paul,
I'm just thinking aloud. Did you try to negate [invert] the error after the subtraction? Because what You describe above might be a positive feedback as well.. And it's very easy to mix up the right order when you subtract.. Depends on in which order /where did you connect the MCLK, VCXO..
Ciao, George
The PI loop is oscillating and not settling on a lock - it will drift into lock for a fraction of a second then out of lock drift again.
I'm just thinking aloud. Did you try to negate [invert] the error after the subtraction? Because what You describe above might be a positive feedback as well.. And it's very easy to mix up the right order when you subtract.. Depends on in which order /where did you connect the MCLK, VCXO..
Ciao, George
All,
I confirm that Finney never sell D1V3 and all sales are from me. Finney did give me some advise on the D1V3 improvement and I confirm that his advice improved the D1 a lot from V2 to V3. One more point, even Finney does not sell the pcb, he is also not having any kind of financial advantage from me.
I know Finney from diyaudio and I find that he is a kind person to share his knowlegde without asking for any kind of return.
Spencer
I confirm that Finney never sell D1V3 and all sales are from me. Finney did give me some advise on the D1V3 improvement and I confirm that his advice improved the D1 a lot from V2 to V3. One more point, even Finney does not sell the pcb, he is also not having any kind of financial advantage from me.
I know Finney from diyaudio and I find that he is a kind person to share his knowlegde without asking for any kind of return.
Spencer
Joseph K said:Paul,
I'm just thinking aloud. Did you try to negate [invert] the error after the subtraction? Because what You describe above might be a positive feedback as well.. And it's very easy to mix up the right order when you subtract.. Depends on in which order /where did you connect the MCLK, VCXO..
Ciao, George
I doubt it. Postive feedback will make the loop go wild quickly. Yes, it's highly possible an over-correction problem. Paul first has to make sure he has a clean and linear DAC output first then tune down the PIC code to make smaller steps.
- Status
- Not open for further replies.
- Home
- Source & Line
- Digital Line Level
- Real or fake PCM63?