[alsa-devel] Monotonic timestamps
mznyfn at 0pointer.de
Thu Apr 10 16:26:45 CEST 2008
On Thu, 10.04.08 09:48, Jaroslav Kysela (perex at perex.cz) wrote:
> > The problem with this is that there seems to be no way to determine
> > from an application if monotonic timestamps are enabled in an
> > snd_pcm_t or not, ALSA just switches over to them, making the
> > timestamps relatively useless, because we cannot reliable relate them
> > to timestamps we query from the kernel ourselves -- because we just
> > don't know if we need to use CLOCK_MONOTONIC or CLOCK_REALTIME.
> Application can just do a simple comparsion between ALSA timestamp and
> gettimeofday() output. The gettimeofday() returns value since the Epoch,
> but CLOCK_MONOTONIC returns time since start of system. Thus, it's really
> easy to see if time matches or not (difference will be very big) to
> detect the time source. Value from gettimeofday() does not make much sense
> in audio (real time) environment.
Uh, this is a really ugly heuristic and is not compatible with the
CLOCK_MONOTONIC docs. Quoting from http://www.opengroup.org/onlinepubs/000095399/functions/clock_getres.html:
If the Monotonic Clock option is supported, all implementations shall
support a clock_id of CLOCK_MONOTONIC defined in <time.h>. This clock
represents the monotonic clock for the system. For this clock, the
value returned by clock_gettime() represents the amount of time (in
seconds and nanoseconds) since an unspecified point in the past (for
example, system start-up time, or the Epoch). This point does not
change after system start-up time.
i.e. it is not mandated by the standard that CLOCK_MONOTONIC is
measured from system bootup. Even more: it is suggested that it might
be relative to the epoch! In that case, distuingishing values returned
by CLOCK_MONOTONIC from CLOCK_REALTIME just by looking on them is
simply not possible.
Yes, I do fully agree that gettimeofday()/CLOCK_REALTIME is not a good
choice for audio programming. But still, the same way as the ALSA libs
fall back to CLOCK_REALTIME when CLOCK_MONOTONIC is not available I
need to do the same in PA. And I have to do it in the exact same
cases. However, I currently can't, since the decision is hidden
inside of ALSA, and the conditions (like the alsa kernel version) are
not really accessible from outside.
> > I find it very strange that ALSA just switches to monotonic timestamps
> > just like that, anyway. Programs written for wallclack timestamps will
> > break if they run on a system where ALSA uses monotonic timestamps!
> It's true, but so far - I don't know about any program using timestamps in
> serious way. Also, timestamps from gettimeofday() are not reliable (for
> example when NTP time synchronization is used in system).
PA would use them in a serious way (to implement timer-based sched).
> > Could anybody please explain the difference between status->tstamp and
> > status->trigger_tstamp for me, please? The doxygen docs are bit too
> > terse on this, I fear.
> I added just these words to trigger tstamp:
> + * Trigger means a PCM state transition (from stopped to running or
> + * versa vice). It applies also to pause and suspend. In other words,
> + * timestamp contains time when stream started or when it was stopped.
Awesome, thanks a lot! This helped!
> The "now" tstamp is obvious, or not? It's just timestamp related to
> current stream position reported in other ALSA functions.
Yes, that was clear to me.
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
More information about the Alsa-devel