Re: [LAD] AoIP question

On Fri, 10 Oct 2014, Winfried Ritsch wrote:

> Am Sonntag, 5. Oktober 2014, 23:35:21 schrieb tom@email-addr-hidden:
>>
> 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
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev