[alsa-devel] Monotonic timestamps

Jaroslav Kysela perex at perex.cz
Thu Apr 10 09:48:19 CEST 2008

On Wed, 9 Apr 2008, Lennart Poettering wrote:

> Hey!


> 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.

> 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).

> 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.

The "now" tstamp is obvious, or not? It's just timestamp related to 
current stream position reported in other ALSA functions.

> Oh, and the code I pasted above will not compile if the #ifdef check
> fails, because of the "else". The "else" should be moved inside of
> #ifddef block.

Thanks. Fixed in our repo.


Jaroslav Kysela <perex at perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

More information about the Alsa-devel mailing list