26 Jan
2009
26 Jan
'09
5:22 p.m.
Hi everyone,
Fons, thanks to your essay "Using a DLL to filter time" [1], that you
mentionned
in a discussion we had in August, I've put together a small library, named
Pendule, for accurate timing within a real time context. It's a tiny piece of
code, but offers a very easy to use replacement for gettimeofday().
Plus, it includes some benchmarking/measuring tools, that produce that sort of
fancy graphics (this one using a PCI hda intel card):
http://www.samalyse.com/code/pendule/shortgraph.png
Usage is very simple. first create an instance:
#include <pendule.h>
Pendule *pendule = pendule_new(buffer_size / sample_rate, bandwidth);
Then, in the realtime thread, update the loop every process cycle:
pendule_cycle(pendule);
And use pendule_gettime() instead of gettimeofday():
double current_time_in_seconds = pendule_gettime(pendule);
As expected, looking at the graph above, the obtained time doesn't drift as the
audio time, and has a lower jitter than the system time. Well, at least, it
works for me.
However, although my measures are pretty encouraging, I am not 100% sure of my
DLL implementation. Could you please review it ? It's there:
http://svn.samalyse.com/pendule/trunk/src/pendule.c
You can grab everything using svn:
svn co http://svn.samalyse.com/pendule/trunk pendule
I'd like to know how it works for others. You can easily test your
hardware/system and make graphs with:
./waf configure
./waf build
./measure
./graph
Check the README for more.
[1] http://www.kokkinizita.net/papers/usingdll.pdf
Best regards,
--
Olivier
27 Jan
27 Jan
3:20 a.m.
Olivier Guilyardi schrieb:
Hi everyone,
Fons, thanks to your essay "Using a DLL to filter time" [1], that you
mentionned
in a discussion we had in August, I've put together a small library, named
Pendule, for accurate timing within a real time context. It's a tiny piece of
code, but offers a very easy to use replacement for gettimeofday().
Plus, it includes some benchmarking/measuring tools, that produce that sort of
fancy graphics (this one using a PCI hda intel card):
http://www.samalyse.com/code/pendule/shortgraph.png
Usage is very simple. first create an instance:
#include <pendule.h>
Pendule *pendule = pendule_new(buffer_size / sample_rate, bandwidth);
Then, in the realtime thread, update the loop every process cycle:
pendule_cycle(pendule);
And use pendule_gettime() instead of gettimeofday():
double current_time_in_seconds = pendule_gettime(pendule);
As expected, looking at the graph above, the obtained time doesn't drift as the
audio time, and has a lower jitter than the system time. Well, at least, it
works for me.
However, although my measures are pretty encouraging, I am not 100% sure of my
DLL implementation. Could you please review it ? It's there:
http://svn.samalyse.com/pendule/trunk/src/pendule.c
hi
instead of gettimeofday() you could use
clock_gettime(CLOCK_MONOTONIC,..) where its available. Its a posix
function and it has the benefit of beeing monotonic, where
gettimeofday() is imho useless if you run ntp.
also in _new() you should probably use calloc, or make sure you init all
fields.
Stefan
You can grab everything using svn:
svn co http://svn.samalyse.com/pendule/trunk pendule
I'd like to know how it works for others. You can easily test your
hardware/system and make graphs with:
./waf configure
./waf build
./measure
./graph
Check the README for more.
[1] http://www.kokkinizita.net/papers/usingdll.pdf
Best regards,
8:49 a.m.
Stefan Kost wrote:
Olivier Guilyardi schrieb:
Thanks for this remark. I did not know clock_gettime(). However, the real
question may not be which clock source is the most reliable, but which one is
used as the master clock.
For example, in FFmpeg, each audio and video packets are tagged using a PTS
which is computed using av_gettime() which calls gettimeofday(). This is the
master timing source to synchronize the audio and video input streams which may
well be generated according to their own clocks.
This is why I thought about adding a new function to the API,
pendule_set_master_time_reader(double (* func) (void)) or similar, that would
allow to set which ever function you like to retrieve the master time. This
function should returned the current time as a double representing the number of
seconds since the Epoch.
[...]
However, although my measures are pretty encouraging, I am not 100% sure of my
DLL implementation. Could you please review it ? It's there:
http://svn.samalyse.com/pendule/trunk/src/pendule.c
instead of gettimeofday() you could use
clock_gettime(CLOCK_MONOTONIC,..) where its available. Its a posix
function and it has the benefit of beeing monotonic, where
gettimeofday() is imho useless if you run ntp. also in _new() you should probably use calloc, or make
sure you init all
fields.
pendule_cycle() must be called before pendule_gettime() or pendule_stats().
That's the way all fields get initialized. Otherwise the results are
undetermined. I suppose stating this in the (to be written) docs should be
sufficient. Initializing values in pendule_new() is irrelevant, since this can
only be done in real-time, which pendule_cycle() is for. For example, setting
current_time to zero (1/1/1970 at midnight) in pendule_new() isn't more relevant
than any other random value to me.
I'll try to add doc blocks to pendule.h soon.
> You can grab everything using svn:
> svn co http://svn.samalyse.com/pendule/trunk pendule
>
> I'd like to know how it works for others. You can easily test your
> hardware/system and make graphs with:
>
> ./waf configure
> ./waf build
> ./measure
> ./graph
>
> Check the README for more.
--
Olivier
9:09 a.m.
On Tue, 2009-01-27 at 13:49 +0100, Olivier Guilyardi wrote:
For example, in FFmpeg, each audio and video packets
are tagged using a PTS
which is computed using av_gettime() which calls gettimeofday().
this should be considered a bug and reported as such to the FFmpeg group
(preferably with a patch to make it use clock_gettime() if available).
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.
--p
9:44 a.m.
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) ?
Ciao,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
O tu, che porte, correndo si ?
E guerra e morte !
28 Jan
28 Jan
6:18 p.m.
Fons Adriaensen wrote:
On Tue, Jan 27, 2009 at 02:07:17PM +0100, Paul Davis
wrote:
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
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) ?
3 Feb
3 Feb
9:30 a.m.
Paul Davis wrote:
On Tue, 2009-01-27 at 13:49 +0100, Olivier Guilyardi
wrote:
I just wanted to let you know that an interesting discussion is going on the
ffmpeg-devel mailing list, about choosing a time source, NTP effects, and A/V
synchronization. It is named "libavdevice: PTS stability and risks of drift".
--
Olivier
For example, in FFmpeg, each audio and video
packets are tagged using a PTS
which is computed using av_gettime() which calls gettimeofday().
this should be considered a bug and reported as such to the FFmpeg group
(preferably with a patch to make it use clock_gettime() if available).
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.
5572
days inactive
5580
days old
linux-audio-dev@lists.linuxaudio.org
6 comments
4 participants
participants (4)
-
Fons Adriaensen -
Olivier Guilyardi -
Paul Davis -
Stefan Kost