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 _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
