Re: [LAD] AoIP question

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
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev