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