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

[Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>]

>>>>> 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?