[LAD] media clock from wall clock

Len Ovens len at ovenwerks.net
Sun Oct 12 15:50:31 UTC 2014

I have been playing with numbers (a little) for AoIP and AES67 (because I 
can actually read the spec). The media clock (AKA wordclock) is derived 
from the wall clock which is synced via PTP. There are 3 sample rates 
supported 44.1k (not sure if any physical devices really do), 48k and 96k.

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. 
It is obvious to me from this, that the true media clock is derived by 
external circuitry. The one "must support format" is 48k at 48 
samples/packet. (both 16 and 24bit on the receive end of a stream) This is 
1ms packet time. (there are AoIP devices that only support AES67 with this 
format) So I am guessing that it must be easy to derive a media clock from 
a 1ms clock input. The computer (CPU board) would have a GPIO with a 1ms 
clock out derived from the cpu wall clock which in turn is kept in sync 
with the network via PTP. I am guessing there is already a chip in 
production that does this with almost no support circuitry.

The side effect of the 1ms/packet standard is that streams are limited to 
8 channels at 48K and 4 channels at 96k. So for more channels more streams 
are required. This maximum comes from the limit that the full packet must 
fit into one standard ethernet packet with the MTU at 1500 (minus headers 
etc.). The transport does not do packet reassembly of fragmented packets 
and basically drops them.

1 ms latency in the jack world is the same as 16/3. This may explain why 
/3 works better for other formats such as USB or FW. It may also be the 
bridge that works best with OPUS at 5 ms.

Len Ovens

More information about the Linux-audio-dev mailing list