13 Oct
2014
13 Oct
'14
9:20 p.m.
On Mon, 13 Oct 2014, Fons Adriaensen wrote:
On Sun, Oct 12, 2014 at 02:42:19PM -0700, Len Ovens
wrote:
Sorry, it didn't take much thought to figure this out. Frequency synth has
been using these kinds of things for years. For some reason my mind got
locked in a divide by two pattern and I missed it. Thank you for your
patience.
I have also been reading more on PTP time bases. It seems almost all of
the better ones are implemented as part of the NIC. There are some NIC
chips that have PTP daemons built in (and they ... the chips, are not that
costly... $5 or so). Even those that do not have a PTP server in them do
seem to have timing functions that can be read and controlled by the OS
and the API has been in the kernel since 3.0ish. Also many of the NICs
(PCIe cards) have pins that can be set to ptp clock frequencies from which
audio word clock could be derived to sync a local AI (d1010 for example)
from network derived Master clock. It seems almost any AoIP setup relies
on this to work. Both AVB and AES67 (and all the proprietary transports
AES67 is based on) use PTP for sync.
http://home.mit.bme.hu/~khazy/ptpd/bf2013.pdf gives an ok overview of some
of the practical setup of a PTP system (including GPS reference...
probably not something needed for AoIP codec sync). It seems practical to
use ptp for mediaclock in one of two ways:
Use PTP to sync the system clock and run a jackd dummy backend from there.
AoIP can then be connected as clients. It is questionable if this is
useful as media clock is only required to sync a local audio device. Also,
the dummy backend has only samples/period and not nperiods(I assume it
uses 2). This is at odds with the AoIP standard of 48 samples per packet
which would require a jack setting of 16/3 for simplicity. (an
intermediate buffer could convert instead but would add latency)
Use the NIC to provide a local media clock (or super clock) and then use
this to sync the local AI and use the local AI to sync jackd using -n3
AES67 is not a wide spread protocol for audio interfaces yet, there are
only two or three that I can find (lots of other equipment though).
However, it seems that a lot of proprientery AIs that will soon support
AES67 as one way of using them.
It seems worth while to support this in Linux for Alsa and jack (I think
starting with jack makes the most sense). It would be "nice" to have an
easy way to generate wordclock so that legacy HW can still be used with it
too. For the development of an open AI that uses the host's NIC to
connect, making AES67 the glue gives such a device a much wider audience.
It seems 1ms latency (or less) is expected as a normal use case which is
about the lower limit of AIs in Liinux anyway.
--
Len Ovens
www.ovenwerks.net
On Sun, 12 Oct 2014, Fons Adriaensen wrote:
What I meant is that it doesn't depend on having 'nice even' numbers.
This is a non-problem. A PLL/DLL (which is what any system that
syncs one clock to another will amount to) can be made for any
ratio of integers.
In HW it is a non-problem. I am not so sure that is true in SW on a
machine that is also running a DE, and a DAW on top of that. That
is, I think that a cpu that has nothing to do but make a media clock
would have no problem doing this.