Fons Adriaensen wrote:
On Tue, Jan 27, 2009 at 02:07:17PM +0100, Paul Davis
wrote:
gettimeofday is a non-linear, non-mononotic clock
if ntp is used. it is
not suitable for timestamping in this way. without ntp, it will work
better, but it is still subject to potential non-monotonicity.
But for the purpose of using or generating OSC timestamps
gettimeofday() is the only one that can be used, since
it is the one shared by all concerned (if they ntp).
How bad is this in practice for an ntp client that
has been running for some time (i.e. after the initial)
adjustments) ?
If I understand things correctly, there is no *right* way to get the system
time, it depends on the context: for absolute timestamps that travel over a
network, such as OSC timetags, gettimeofday() is needed. If the timestamps are
meant to stay within a system that has a single master clock, then
clock_gettime() is the way to go.
In this regard, ffmpeg should indeed use clock_gettime() because AFAICS, the
timestamps are only used to synchronize audio and video, during the conversion
operations, within a single application, on a single computer.
But, when developing a ffmpeg component (muxer, demuxer, ..), one shouldn't call
gettimeofday() nor clock_gettime() I think. One must calls av_gettime() which
hides the way the time is retrieved, for consistency with the ffmpeg API.
So, back to Pendule, I think I shouldn't call any of these functions, but let
the user retrieve the system time as he/she wishes.
That could be done by changing pendule_cycle() (which must be called at the very
start of the process callback, to update the DLL filter) into:
void pendule_update(double system_time);
This also has the advantage that in the case of JACK, one could subtract the
value of jack_frames_since_cycle_start() from the system time passed to
pendule_update(), to get closer to the exact time the current cycle started.
Is this correct to you?
--
Olivier