[LAD] AoIP question

[Len Ovens]

On Sun, 5 Oct 2014, Fons Adriaensen wrote:

> On Sun, Oct 05, 2014 at 01:51:36PM -0700, Len Ovens wrote:
>
>> AES67 (and other formats) use PTP (IEEE 1588-2008) to keep the
>> system clocks aligned at a usec level. The media clock is then
>> derived from that. The media clock on both systems should therefore
>> be syncronis.
>
> It's easy to write in a standard that
>
>  'The media clock is then derived from that'.
>
> Doing it is another matter. It requires either controlling
> the HW sample rate (which is the 'media clock' for audio)
> or resampling.

Yes that is correct. In general, the IF is a separate box or boxes and the 
derivation of media clock is done by those boxes. Taking a computer with 
an ALSA card and syncing that card to the network clock is not something 
any of the audio cards I have worked with can do (you mention the RME may 
be able to). However, an AoIP box or set of boxes could be used in place 
of a computer audio IF. They would send the audio packets to the computer 
at a fixed rate  and the computer would send output packets based on the 
same rate back to the interface(s). This is not fundamentally different 
from how ALSA cards work. The computer would not even have to have access 
to the media clock or the PTP time base in order to work. That is with one 
computer. With two or more computers, one computer may use another 
computer as a direct source at which point using the PTP timing may be 
needed (I could be wrong on that too, presending packets before the sample 
clock for that packet timed could be just as effective so long as all 
codecs are synced).

To repeat, all ADC/DAC hw has to be on a box that can take the PTP clock 
and derive media clock (AKA sample or word clock) for that HW. Most ALSA 
cards would require a wordclock for an external source such as one of the 
AoIP IF boxes that was physically close... but then why not just use the 
AoIP box?

So having Linux support AES67 does not mean adding the ALSA audio Card to 
the AES67 I/Os at all, it means being able to access that AES67 audio for 
processing such as recording, editting, etc.

To put this into persepective, I have a machine that has an AC97 AI on the 
MB, I also have an ICE1712 card in the PCI slot. In practice this means 
That the MB audio card is turned off and I only use the ICE as an audio 
IF. In the case of AoIP Audio IF box it would be the same. The internal 
audio would not be used in favour of the AoIP I/Os. The big difference is 
that one can use as many external AoIP boxes as they wish (so long as the 
cpu/ethernet port will handle the traffic) and it will all look like one 
audio IF. The difficulty with either jack or ALSA is that they don't 
expect the audio interface to grow new I/O or have them disappear after 
they have been started, but AoIP is designed for that to happen at any 
time without anything more than having connections break. Jack would be 
able to handle this somewhat better... Using PTP on the computer to run a 
dummy backend for timing and only connecting streams as clients. The 
clients would be in sync with the PTP run jack backend. The available 
streams  might even be none and jack could still run. Jack could supply 
streams without having any input streams as may happen with a soft synth.

This is a new thing for linux systems and a new way of thinking. I think 
it pretty much breaks ALSA as I know it. This does not mean AoIP boxes can 
not be used as audio devices with ALSA, they could be used in a static 
manner. That is one AoIP box could be set up with the system  with a set 
number of I/O and opperate just like an internal AI. Any change in the 
setup by adding a second box would mean restarting the audio module.

--
Len Ovens
www.ovenwerks.net