[LAD] media clock from wall clock
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.
More information about the Linux-audio-dev