[LAD] AoIP question

[Len Ovens]

On Fri, 10 Oct 2014, Winfried Ritsch wrote:

> Am Sonntag, 5. Oktober 2014, 23:35:21 schrieb tom at trellis.ch:
>>
> just to add another options and be a wiseacre :
>
> On a microchip dsPIC [1] you can adjust the internal oscillator (RC) (where
> also the sample clock for DA is derived) in a small range of 10%, so it is
> possible to use PTP for sample-exact synchronization (I did do a "soft PLL"
> for a low cost solution of a DA to avoid re-sampling and big buffers). I was
> told on ARMs Oscillator tuning is also possible, and if audiohardware derives
> clocks from it, it can also be tuned and used as soft PLL.

I am sure this is what the AoIP boxes do
>
> Anyway there are Chips [2] which can generate sample-clocks (Master-Clock)
> from a PTP signal, so if your audiohardware supports Master-Clock, you can add
> such a chip ;-).

An easier solution might be to create a jack client that uses the jack 
callback timing to keep the system clock in time so it could be a ptp 
master. Then the AoIP IFs would lock to that. (stability? who knows) I 
think in general, for most people, either going all AoIP, or running 
wordclock from the AoIP side to the computer AI would be better.

The only time someone is likely to want to use an internal audio IF is if 
they already have one and are adding more i/o via AoIP. In such a case, an 
external sync solution is best. Someone who is building a system from the 
ground up will use all AoIP in the first place.

Any computer connected to this network should be able to work with the 
audio using PTP as an internal time base for packet timing. Packets 
normally have a number of samples in each (AES67 uses from 6 to 192 
samples per packet, 48 being sort of standard) 48 samples per packet would 
be like jack running 16/3. So an audio packet comes in, we look at the 
time in usec(wall clock) and calculate how many usec we have left of 48 
samples (we make it just a bit less in case our wall clock is slow) When 
that time is up we send the output packet. In this way we can track 
under/over runs internally and not use ptp at all. Using ptp would not be 
hard though and would make the interface less sensitive to packet delays 
caused by network switching etc.

The use of ptp for sync can be used for keeping time records and syncing 
video to audio, but the general use in this case is to keep a number of 
audio IFs in sync. Rather than sending wordclock through the net, 
wordclock is calculated from the wall clock. The wall clock is a raw 
number of usecs since 1970 and so the next wordclock is always a fixed 
number of usec from the last. PTP just keeps the same wall clock in all 
devices. In the case of a computer using the audio without it's own audio 
IF, word clock is not needed but "packet clock" is used instead.

The absolute accuracy of the overall system time is based on the clock 
being used as master. I do not know how good the clocks in AoIP interfaces 
are (it has already been stated that computer clocks are cheap and dirty), 
but musicians have been using cheap tuners with good results for ages. The 
next step up would be simple addition of a GPS clock to sync the master 
too.

--
Len Ovens
www.ovenwerks.net