Re: [RFC - AAF PCM plugin 3/5] aaf: Implement Playback mode support

["Guedes, Andre" <andre.guedes@intel.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3336 bytes --]

On Thu, 2018-08-23 at 13:51 -0500, Pierre-Louis Bossart wrote:
> > > > > > Every time aaf->timer_fd expires, the audio buffer is
> > > > > > consumed
> > > > > > by
> > > > > > the
> > > > > > plugin, making some room available on the buffer. So here a
> > > > > > POLLIN
> > > > > > event is returned so alsa-lib layer can copy more data into
> > > > > > the
> > > > > > audio
> > > > > > buffer.
> > > > > > 
> > > > > > > When there are two audio clock sources or timers that's
> > > > > > > usually
> > > > > > > where
> > > > > > > the fun begins.
> > > > > > 
> > > > > > Regarding scenarios with two audio clock sources or timers,
> > > > > > the
> > > > > > plugin
> > > > > > doesn't support them at the moment. This is something we
> > > > > > should
> > > > > > work on
> > > > > > once the basic functionality is pushed upstream.
> > > > > 
> > > > > I was talking about adjusting the relationship between your
> > > > > CLOCK_REALTIME timer and the media/network clock. I don't
> > > > > quite
> > > > > get
> > > > > how
> > > > > this happens, I vaguely recall there should be a daemon which
> > > > > tracks
> > > > > the
> > > > > difference between local and media/network clock, and I don't
> > > > > see
> > > > > it
> > > > > here.
> > > > 
> > > > Oh okay, I thought you were talking about something else :)
> > > > 
> > > > I believe you are referring to the gptp daemon from Openavnu
> > > > [1].
> > > > The
> > > > AAF plugin doesn't use it. Instead, it uses linuxptp [2] which
> > > > is
> > > > distributed by several Linux distros.
> > > > 
> > > > Linuxptp provides the phc2sys daemon that synchronizes both
> > > > system
> > > > clock (i.e. CLOCK_REALTIME) and network clock (i.e. PTP clock).
> > > > The
> > > > daemon disciplines the clocks instead of providing the time
> > > > difference
> > > > to applications. So we don't need to do any cross-timestamping
> > > > at
> > > > the
> > > > plugin.
> > > 
> > > Humm, I don't get this. The CLOCK_REALTIME is based on the local
> > > oscillator + NTP updates. And the network clock isn't necessarily
> > > owned
> > > by the transmitter, so how do you adjust?
> > 
> > When phc2sys is running, CLOCK_REALTIME is based on local
> > oscillator +
> > phc2sys updates. The daemon keeps adjusting CLOCK_REALTIME based on
> > PTP
> > clock via clock_adjtime syscall.
> 
> Is this a desirable "feature"? You may want to run other non-audio 
> applications where the NTP clock makes sense, e.g. to know when your 
> next call is, while playing audio on an external amp. Looks to me
> that 
> you've simplified the problem too much, or this is for custom audio-
> only 
> solutions. What am I missing?

The plugin requires both CLOCK_REALTIME and PTP to be synchronized, and
this can add some usage scenarios limitation, indeed.

However, the scenario you described looks still feasible. For instance,
at the host running as PTP master, we could have NTP disciplining
CLOCK_REALTIME (ntp daemon) and CLOCK_REALTIME disciplining PTP
(phc2sys daemon). At the hosts running as PTP slave, we have PTP
disciplining CLOCK_REALTIME (phc2sys daemon). This way, CLOCK_REALTIME
time from all systems is NTP time while CLOCK_REALTIME and PTP clock
are in sync. Makes sense?

- Andre

[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3262 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]