[pulseaudio-discuss] [PATCH 4/4] Wrap clock_gettime and friends

Lennart Poettering lennart at poettering.net
Fri Oct 30 17:41:19 PDT 2009

On Mon, 19.10.09 12:45, Daniel Mack (daniel at caiaq.de) wrote:

> > And clock_gettime we don't really need either. We need some kind of
> > accurate system timers (preferably monotonic), and on Linux we use
> > clock_gettime() for that. But we already have a fallback there for
> > gettimeofday().
> > 
> > Or in other words, the current APIs pa_rtclock_get(),
> > pa_rtclock_hrtimer() is supposed to be the abstract API that has
> > different backends on different systems. I'd very much prefer if any
> > MacOS specific code would simply be plugged in there instead of
> > creating various new abstraction interfaces!
> Ok - what about the version below? I don't particularily like the
> #ifdeffery jungle, but it is a lot less code now.

Thanks.  Looks much better. I reordered things a little now and merged
this. Please verify that I didn't break the MacOS code while I did that!

One thing though: ideally pa_rtclock_get() should return monotonic time,
i.e. time that is independant from NTP, from timezone changes, from
the user manipulating the system time. This is what on Linux is used
if CLOCK_MONOTONIC is available. Only if it is not available we fall
back to the unreliable wallclock time, i.e. CLOCK_REALTIME.

Now, if I read
I see a microuptime() call referenced there and I wonder if this
wouldn't be mre suitable for our needs? The epoch of CLOCK_MONOTONIC
is not defined, but usually system bootup, so this would match more
closely, and uptime should be strictly monotonic, too.

Thanks for your work,


Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

More information about the pulseaudio-discuss mailing list