[time-nuts] Clocks for Audio gear

[Azelio Boriani]

You can refer to this for a relation between SFDR and INL:

http://www-inst.eecs.berkeley.edu/~ee247/fa07/files07/lectures/L14_f07.pdf


On Wed, May 9, 2012 at 11:25 PM, Hal Murray <hmurray at megapathdsl.net> 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.
>
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>