Hi All,
Been following here lot’s of postings on Clocks, DAC designs, CDP mods etc. but very few (if any at all) address the digital chain as a whole. My own pursue for better sound has always been from a systems approach: improving one of its components reveals the next bottleneck of the system; hence my next project is born.
As a side step: from the whole power cord discussions in the analog domain I learned that without a systems approach any change is a shot in the dark: grounding, shielding, balancing etc. are all part of the chain to get meaningful results. (Pete Goudreau has a wonderful paper on that: http://www.sstage.com/articles/pete01.htm).
But for the sake of this digital forum, what about a systems approach in the digital chain? All components CD, CD X-port, Interconnect (S/PDIF / I2S) and DAC in the chain do influence to some extent the sound of the system. To name a few of my own experiences:
S/PDIF:
Of little value is discussing S/PDIF cabling if Zin is not equal to Zout. Proper matching (Refl Att > 30dB) to show the effect of transformer quality in S/PDIF (induced jitter etc). It was after using high quality x-formers, proper connectors started to show a difference.
Clock:
Introducing a good clock did make a difference but, reclocking the S/PDIF output in the CD X-port made a difference only after the clock was improved. Some report that clock improvement makes the sound harse. Congrats, you just found a reason for your next project.
CD X-port:
After introducing a better clock + reclocking, a complete redesign of my CEC power supply showed even much more improvement.; hence improve clocking & S/PDIF reclocking are not the end of the quest, even with my DAC which has its own reclocking. Yes, even with good DAC's, transports do matter!
Ergo, imho there is much to learn from a systems approach of the digital chain as a whole and good engineering of the components in the system is a must to play the top league. E.g. During my experiments with shielding, grounding, etc (see above), measuring it's effect on (induced) jitter in my DAC gave me lot's of insights on the subject.
To learn which modifications / improvements really do matter, and to save energy/money on our quest to good sound, may I suggest to start this thread and share experiences of component improvements with respect to the rest of the digital system as a whole? Not necessarily to stay in the digital domain, as long as it concerns digital sourcing.
You’re insights much appreciated.
rgrds,
/Peter
Been following here lot’s of postings on Clocks, DAC designs, CDP mods etc. but very few (if any at all) address the digital chain as a whole. My own pursue for better sound has always been from a systems approach: improving one of its components reveals the next bottleneck of the system; hence my next project is born.
As a side step: from the whole power cord discussions in the analog domain I learned that without a systems approach any change is a shot in the dark: grounding, shielding, balancing etc. are all part of the chain to get meaningful results. (Pete Goudreau has a wonderful paper on that: http://www.sstage.com/articles/pete01.htm).
But for the sake of this digital forum, what about a systems approach in the digital chain? All components CD, CD X-port, Interconnect (S/PDIF / I2S) and DAC in the chain do influence to some extent the sound of the system. To name a few of my own experiences:
S/PDIF:
Of little value is discussing S/PDIF cabling if Zin is not equal to Zout. Proper matching (Refl Att > 30dB) to show the effect of transformer quality in S/PDIF (induced jitter etc). It was after using high quality x-formers, proper connectors started to show a difference.
Clock:
Introducing a good clock did make a difference but, reclocking the S/PDIF output in the CD X-port made a difference only after the clock was improved. Some report that clock improvement makes the sound harse. Congrats, you just found a reason for your next project.
CD X-port:
After introducing a better clock + reclocking, a complete redesign of my CEC power supply showed even much more improvement.; hence improve clocking & S/PDIF reclocking are not the end of the quest, even with my DAC which has its own reclocking. Yes, even with good DAC's, transports do matter!
Ergo, imho there is much to learn from a systems approach of the digital chain as a whole and good engineering of the components in the system is a must to play the top league. E.g. During my experiments with shielding, grounding, etc (see above), measuring it's effect on (induced) jitter in my DAC gave me lot's of insights on the subject.
To learn which modifications / improvements really do matter, and to save energy/money on our quest to good sound, may I suggest to start this thread and share experiences of component improvements with respect to the rest of the digital system as a whole? Not necessarily to stay in the digital domain, as long as it concerns digital sourcing.
You’re insights much appreciated.
rgrds,
/Peter
Interesting article Peter, i will read it and may be used as a guideline for next projects. I had thoughts like this also, but not that deep.
Every single part i changed on my gear has its influence, big or subtle.
Bought once a new solid cupboard for books and also for the equipment, result: sound-improvement. And a different PS for a separate clock can change the whole sound.
Curious what this thread will bring, and going to follow this thread.
Every single part i changed on my gear has its influence, big or subtle.
Bought once a new solid cupboard for books and also for the equipment, result: sound-improvement. And a different PS for a separate clock can change the whole sound.
Curious what this thread will bring, and going to follow this thread.
The digital chain is about getting 1's and 0's to the dac, at the correct data rate. No more, no less.
There are two issues.
(1) Make sure there are no errors. This is not a problem, we can successfully read a cd at 16-52x and transmit data at gigabits per second on unshielded copper wires. 1x at 1.2mbits pales compared to that.
(2) Feed the bits to the dac at exactly the right moment. That's what buffers and good clock generators are for. Go for a dac with buffer and internal clock and you're out of the big bad jitter devil.
As long as these two points are reached, it doesn's matter what caps, cables or snake oil you're using. It doesn't matter if those bits are coming from cd, hdd, network, modem, aliens or a _very_ fast morse typist.
Sadly few people understand that digital is a complete different beast than analog and tend to apply all the analog knowledge to digital. The result varies from funny to pathetic.
There are two issues.
(1) Make sure there are no errors. This is not a problem, we can successfully read a cd at 16-52x and transmit data at gigabits per second on unshielded copper wires. 1x at 1.2mbits pales compared to that.
(2) Feed the bits to the dac at exactly the right moment. That's what buffers and good clock generators are for. Go for a dac with buffer and internal clock and you're out of the big bad jitter devil.
As long as these two points are reached, it doesn's matter what caps, cables or snake oil you're using. It doesn't matter if those bits are coming from cd, hdd, network, modem, aliens or a _very_ fast morse typist.
Sadly few people understand that digital is a complete different beast than analog and tend to apply all the analog knowledge to digital. The result varies from funny to pathetic.
Your short-sighted approach leaves out the fact that SPDIF means that there is a PLL to recover the clock. You can belive the "bits is bits" reasoning, that only takes into account errors if you want.
You can ignore "analog" knowledge if you feel comfortable. You will never achieve accurate sound if you do so.
Jocko
You can ignore "analog" knowledge if you feel comfortable. You will never achieve accurate sound if you do so.
Jocko
danb1974 said:
Hi
You assume you van achieve sufficient isolation, and regenerate a sufficiently low jitter clock. in practice 2 problems arise
1 - The ears is VERY sensitive to errors induced by jitter
2 - Practical implementations suffer from crosstalk (buffers have in and outputs and a commmon part called substrate). Achieving sufficient isolation calls for analogue approach.
Indeed, it shouldn't matter where the data comes from. The most important is the conversion proces. That is understood by many and is a fully analogue problem. Luckilly, otherwise digital wouls still sound as crappy as in the early days.
Now please back to Peters' post, very interesting subject.
best
i was always taught that digital is a specialized subset of analog and those digital guys would do well to remember that.
maybe you're referrring to the different approaches, techniques, rules of thumb, etc. needed for successful designs between "lower" frequency design and "higher" frequency design?
mlloyd1
maybe you're referrring to the different approaches, techniques, rules of thumb, etc. needed for successful designs between "lower" frequency design and "higher" frequency design?
mlloyd1
danb1974 said:
Nice thread!
Just to remind everyone that a good design and best components still won't approach the ultimate nirvana if we don't think interconnects - all designs I saw on these forums completely overlook this. Or just forget to state the importance.
My approach starts with the box itself, observe how everything is connected together, and work downstream: blocks and interconection, down to the layout, noise, and at the end - components. Or other way around. It is more logical for me to work downstream, the box / unit is the first thing I see when I start doing modifications. However, I always strat with components, and finish with blocks' wiring.
Everything is important, so do not overlook anything and do not priorities any stage of the given design. Aproach each stage with equal attention.
Extreme_Boky
Just to remind everyone that a good design and best components still won't approach the ultimate nirvana if we don't think interconnects - all designs I saw on these forums completely overlook this. Or just forget to state the importance.
My approach starts with the box itself, observe how everything is connected together, and work downstream: blocks and interconection, down to the layout, noise, and at the end - components. Or other way around. It is more logical for me to work downstream, the box / unit is the first thing I see when I start doing modifications. However, I always strat with components, and finish with blocks' wiring.
Everything is important, so do not overlook anything and do not priorities any stage of the given design. Aproach each stage with equal attention.
Extreme_Boky
Someone here sounds just like one of my old bosses. He did not understand that digital is analog with only 2 voltage levels. Piece of cake. Nor could he comprehend that all of the system problems that we had, trying to pump data in the several hundred megabits range (this was years ago.........gigabit data had not come along yet) was caused by analog issues. Bandwidth, noise, amplitude/phase distortion, jitter...........also known as phase modulation in this case...........were the gremlins that they had to pay analog cowboys like me to solve.
And yes.......I outlasted him at that job.
Jocko
And yes.......I outlasted him at that job.
Jocko
Guido Tent said:
The siren song of a clockmonger. I’d believe it if the samples etched on a CD were an accurate representation of the amplitude of the analog signal at each sample point, but they’re not. First there is quantization error. That error is in the range of +/- ½ LSB for every sample. To decorrolate the quantization noise from the signal, dither is added to the recording. Dither is just pseudo-random noise; sort of like jitter. In essence, the two LSB of every sample on a CD are just random noise. If the two-bit dither is enough to mask the quantization noise, why isn’t it enough to also mask the effects of jitter, which are considerably less than +/- ½ LSB? It seems lots of folks here claim to hear jitter but no one seems to hear dither or any of the many other faults, anomalies, and errors in digital audio.
Theoretically, jitter has the most damaging effect on high slew-rate signals. Coincidently, high slew-rate signals is where DACs have their worst performance. Settling time is the time it takes for the DAC to slew half scale and get to within 1 LSB of where it's going. The fastest multibit DACs settle in about 250ns. That means, ¼ millisecond after the DAC gets the signal to start the conversion, it’s output still has an error of about 1 LSB. Of course, that 1 LSB is random noise; so the error is not an error in the recreation of the original analog waveform but an error in the shape of the added pseudo-random noise (dither.) What difference does it make if the DAC settles to within 1 LSB of the correct output of pseudo-random noise in .250000 or .250001us?
Guido Tent said:
In one picosecond sound travels about 1/3 of a nanometer. If my calculations are correct, 1/3 nm is less than the mean free path of a molecule in air. That means Mr. Tent can distinguish 1 ps of random clock jitter from +/- 1 (net) molecular collision in the propagation time of the sound wave from the speakers to his ears for each and every sample period. That’s amazing! Especially since the lowest level details of the recording are just PSEUDO-RANDOM NOISE!!! How does one distinguish between plain pseudo-random noise and pseudo-random noise with a small amount of added random noise?
Highly entertaining to see noise, dither, settling time, slew rate and quantisation get so totally mixed up with such aplomb.
Jitter is phase modulation. Properly dithered quantisation is additive (pseudorandom) noise. Most jitter in CD players is not random. Since music isn't random either the phase modulation products too won't be random.
They won't be negligible either. Suppose you have one ps of jitter cycle-to-cycle on a 11.2896MHz clock caused by the 75Hz frame rate. Calculating back to deviation from ideal sampling time that's around 75ns worth of absolute wobbling back and forth. This kind of performance is not unusual in a CD player, including many that are otherwise well-designed. Precisely because they are often designed by engineers who reason like mr. Ulas and conclude it's fine to stick any ol' crystal oscillator on the digital supply of the CD decoder electronics.
This should suffice to explain why a clock upgrade is almost guaranteed to be a good investment, *especially* when the player itself has cost a good amount of money.
Where is it said that DACs perform worse at high slew rates? Although they certainly don't get any better, practical performance is far from being limited by slew-rate related mechanisms (jitter aside!). If not, THD+N would rise with frequency at a rate of 6dB/oct. I'm not seeing anything like this happening in even the very cheapest DAC chips.
Settling time of DACs is also irrelevant. It is fairly constant and therefore produces only a pulse shape error, translating into a frequency response error (negligible at 20kHz). Interesting to see this issue brought forward in a discussion concerning jitter.
Jitter is phase modulation. Properly dithered quantisation is additive (pseudorandom) noise. Most jitter in CD players is not random. Since music isn't random either the phase modulation products too won't be random.
They won't be negligible either. Suppose you have one ps of jitter cycle-to-cycle on a 11.2896MHz clock caused by the 75Hz frame rate. Calculating back to deviation from ideal sampling time that's around 75ns worth of absolute wobbling back and forth. This kind of performance is not unusual in a CD player, including many that are otherwise well-designed. Precisely because they are often designed by engineers who reason like mr. Ulas and conclude it's fine to stick any ol' crystal oscillator on the digital supply of the CD decoder electronics.
This should suffice to explain why a clock upgrade is almost guaranteed to be a good investment, *especially* when the player itself has cost a good amount of money.
Where is it said that DACs perform worse at high slew rates? Although they certainly don't get any better, practical performance is far from being limited by slew-rate related mechanisms (jitter aside!). If not, THD+N would rise with frequency at a rate of 6dB/oct. I'm not seeing anything like this happening in even the very cheapest DAC chips.
Settling time of DACs is also irrelevant. It is fairly constant and therefore produces only a pulse shape error, translating into a frequency response error (negligible at 20kHz). Interesting to see this issue brought forward in a discussion concerning jitter.
Are your ears not that good Ulas? oh
Our ears can tell us wether the sound is right or not, they still are very sensitive.
I compare Jitter with a bad percussionist: Simon Phillips or P. Collins weren't that popular if they had a slight variation in pitch. The whole band and music would suffer from the variations in frequency, just as the digital system can suffer from jitter. And its because of the efforts of those few clock-mongers here we can listen to digital music with more emotions, the music-performer's emotions want to share with us on their recordings. The same "clockmonger" Mr. Tent you are talking of has written an article in an (unfortunately seized) Dutch magazine Audio & Techniek, i think in 1997 allready, about EMC in audio, the article resembled at many points the JPS Labs one, but Mr. Tent added very practical diy-solutions to reduce EMC- intervention in our audio gear.
Jitter means bits are not arriving at the correct moment in time. And yes if you are using recovered clock you will run into trouble if the signal has jitter, because your clock will follow more ore less those variations.
But nothing stops you in using a small ram memory acting as a buffer and a quality (stable) clock by which you extract data from the buffer and feed it to the dac.
At least one good (imho) cdplayer (creek cd50 mk ii) does exactly this trick to avoid jitter. And uses a cdrom transport with an ide bus to extract data in dae mode.
What does surprise me is that nobody seems to notice this simple but efective solution. Insted everybody yells "jitter" and keeps using old audio-only 1x/2x transports and unbuffered dacs.
But nothing stops you in using a small ram memory acting as a buffer and a quality (stable) clock by which you extract data from the buffer and feed it to the dac.
At least one good (imho) cdplayer (creek cd50 mk ii) does exactly this trick to avoid jitter. And uses a cdrom transport with an ide bus to extract data in dae mode.
What does surprise me is that nobody seems to notice this simple but efective solution. Insted everybody yells "jitter" and keeps using old audio-only 1x/2x transports and unbuffered dacs.
danb1974 said:
Hi
If jitter is that high that data does not get clocked in correctly, something is realy wrong. We are not discussing these situations.
The RAM suggestion will never yield 100% isolation due to various crosstalk mechanisms. It is ofcourse an improvement.
Higher speed CDrom drives do not have advabtages over "old" technology, mainly because their layout and supply architecture suffered from the marketing department (price).
Finally, the jitter level at the DAC chip is afdfected by many parameters. The drive is one of them, but the clock itself (+ power5 supply) plays a dominant role.
Once you have improved these, you may run into other system limitations - the start of this thread.
best
Hi
I must say that mr.Ulas in some extent is right: you cannot hear jitter... at least as far as you cannot "hear" that a human player has a good sense of rhythm.
Is when you stop hearing sounds, and start listening to music, that you can better get the (not at all small) difference...
However, there are forms of jitter more difficult to detect, or that present themselves under completely different forms: for example asynchronous reclocking in ZO does not make you loose the rhythm too much, possibly because ZO is just a little less sensitive to jitter, or perhaps we are a little less sensitive to ZO jitter than to oversampling DAc jitter.
The most evident effect in this case is that it apparently adds a lot of "audible" high frequencies, which are evidently phantoms, as they do not appear at all in a static frequency response. As all the phantoms I know, thay are somewhat strange, would say ghostly, but you cannot have everything in your life...
All this said, I should better clarify that jitter is quite important indeed for me too...
Giorgio
giorgio@tnt-audio.com
I must say that mr.Ulas in some extent is right: you cannot hear jitter... at least as far as you cannot "hear" that a human player has a good sense of rhythm.
Is when you stop hearing sounds, and start listening to music, that you can better get the (not at all small) difference...
However, there are forms of jitter more difficult to detect, or that present themselves under completely different forms: for example asynchronous reclocking in ZO does not make you loose the rhythm too much, possibly because ZO is just a little less sensitive to jitter, or perhaps we are a little less sensitive to ZO jitter than to oversampling DAc jitter.
The most evident effect in this case is that it apparently adds a lot of "audible" high frequencies, which are evidently phantoms, as they do not appear at all in a static frequency response. As all the phantoms I know, thay are somewhat strange, would say ghostly, but you cannot have everything in your life...
All this said, I should better clarify that jitter is quite important indeed for me too...
Giorgio
giorgio@tnt-audio.com
Giorgio said:
Hello Giorgio,
When "absolute timing" is considered, 1 ps obviously is non-sense. But that is not why the low jitter values are critical. And yes, you are right, jitter as such can't be "heard", only the effects.
The ps comes in at the conversion, once timing errors create amplitude errors. Those still thinking in 1/2 lsb or -96dB noise level as being the limit of what you can hear (hence derive what jitter level should be sufficient) should reconsider their assumptions (and calciulations): The ear is much more sensitive.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.