[LAD] media clock from wall clock

Len Ovens len at ovenwerks.net
Mon Oct 13 19:19:41 UTC 2014


On Mon, 13 Oct 2014, Fons Adriaensen wrote:

> On Sun, Oct 12, 2014 at 02:42:19PM -0700, Len Ovens wrote:
>> On Sun, 12 Oct 2014, Fons Adriaensen wrote:
>>>
>>> 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.
>
> What I meant is that it doesn't depend on having 'nice even' numbers.

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



More information about the Linux-audio-dev mailing list