Re: [LAD] media clock from wall clock

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
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev