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