[time-nuts] Clocks for Audio gear

[MailLists]

Hearing tests showed the ability to discern jitter above a few hundred 
nanoseconds rms.
http://amorgignitamorem.nl/Audio/Jitter/Detection%20threshold%20for%20distortions%20due%20to%20jitter%20on%20digital%20audio%2026_50.pdf

Others claim the ability to detect jitter in the picoseconds range...

It would be a conservative assumption that jitter in the range of 
tens-hundreds of picoseconds will be practically not discernible.

Usually integrated oscillators are composed of the classical inverting 
gate oscillator, with external CQC, and selfbiasing R, which has 
practically no rejection (~6dB) of the power supply noise. As it's 
usually on the same die with noisy digital circuitry, the gate threshold 
will jump around, producing timing errors, also the slew-rate is quite 
low, which just worsens the situation.

As most digital circuitry is less affected by jitter, the best solution 
is to place a clean oscillator near the D/A conversion, where the most 
critical timing point is, and through buffers clock the rest of the 
digital circuits - eventually galvanic isolation might be implemented, 
to pollute less the analog part with digital noise.
To minimize jitter, digital clock inputs should be driven by fast 
slew-rate circuitry.


On 5/10/2012 12:25 AM, Hal Murray wrote:
> was Subject: Re: [time-nuts] Faster than light of a different type
> (Probably my fault.)
>
> actast at hotmail.com said:
>> What I found funny was that the Audiophlie and light thread drew such
>> attacks when it hit home to me as exactly what the Time-Nuts mission is
>> about.  The Audio thread touched on some real world time and freq research
>> ...
>
> I too enjoyed the technical discussions.  Thanks for your contributions.
>
> It's the audiophool bashing that people are complaining about.  Sure, it's
> fun, but only at the right time and it gets old quickly.  The problem is that
> with large groups, there are different opinions of when and how much is
> appropriate.  The long tail on opinions of reasonable can annoy a lot of
> people.
>
> -----------
>
> Back to technical stuff...
>
> As a practical matter, is clock jitter or phase noise from a typical low cost
> crystal and decent board layout a significant problem in audio gear?  How
> hard is it to measure?
>
> Is clock accuracy a practical problem?  How good are people with perfect
> pitch?  It wouldn't surprise me if there are a few that are much much better
> than others, but how good is that relative to 50 PPM which I can get in a low
> cost crystal?
>
> Video geeks solved their clock distribution problems by using frame buffers.
> Is there a similar trick for audio?  Is there a need for it?
>
> --------
>
> I know clocking is a serious problem in fancy DSP systems.  For example,
> modern radar has gone digital.  In that context, clock jitter can be
> important.  Standard procedure is don't run your clock through a FPGA because
> it will add jitter.
>
> Part of the problem is that they are doing magic down conversion in the ADC.
> (I can't think of the term.)  Suppose you have a 100 MHz signal with a 1 MHz
> bandwidth.  You don't have to sample at 200 MHz.  You can sample at 2 MHz and
> your signal will alias down.  It's turning what is normally a bug into a
> feature.  The catch is that the errors/noise due to clock jitter happens at
> the high frequency, in this case multiplying the noise by 100.  (Your
> sample/hold at the front end has to work at the high frequency and your
> anti-aliasing filter gets more interesting.)
>
> There has been an interesting change in the specs for ADCs and DACs over the
> past 20(?) years.  They used to be specified using terms like DNL and INL and
> No-missing-codes.  Modern high-speed ADCs are specified with terms like ENOB
> and SFDR.  Data sheets often include several plots of a batch of samples run
> through a DFT so you can see the noise floor and such.
>
> Here is a reasonable glossary:
>    http://pdfserv.maxim-ic.com/en/an/AN641.pdf
>
> I don't remember comments/specs about clock jitter in the data sheets but I
> haven't looked at one in a few years.  I'll have to keep an eye out the next
> time I'm browsing.
>
>
>