On Sun, 12 Oct 2014, Fons Adriaensen wrote:
On Sun, Oct 12, 2014 at 08:50:31AM -0700, Len Ovens
wrote:
The first thing I find is that it is not possible
to get even word
clock via simple math. The wall clock moves one tick per usec which
at 48K is 20.833rep. (44.1k is a mess) I would suggest this is why
AVB and AES67 at lowest latency already uses 6 sample frames which
is a nice even 125 usec.
This is a non-problem. A PLL/DLL (which is what any system that
syncs one clock to another will amount to) can be made for any
ratio of integers.
In HW it is a non-problem. I am not so sure that is true in SW on a
machine that is also running a DE, and a DAW on top of that. That is, I
think that a cpu that has nothing to do but make a media clock would have
no problem doing this.
The real problem here (but it's not a new one,
solutions for
this have been known for a long time) is a different one.
If the media clock is to be used for actual AD/DA conversion
(and oterwise you don't need it) it needs to have very low
jitter aka phase noise.
That all makes sense. My thought is that because it would only be needed
to sync codec HW, the PLL/DLL would best be done within the same HW as the
codec rather than trying to do the same thing in SW.
When you multiply a frequency by a factor of N then
within
the BW of the control loop the phase noise density will be
multiplied by N^2. So you need a PLL/DLL with a very low BW.
Which normally means that the capture range will be very
small as well, and the loop may never lock for typical
initial conditions. As said there are solutions for this,
but you need to design for it.
OK, that makes sense. I understand the basic idea of the pll and reading
about the dll, I can see how that works too. I am guessing that the reason
that AES3 can have such a wide range of capture is that it is already at
the right frequency... or higher. (AES3 capture is often from 32k
to 96k) So the jitter is the same as the source?
--
Len Ovens
www.ovenwerks.net