Monotonic timestamps

Monotonic timestamps

[Lennart Poettering]

Hey!

I saw that ALSA 1.0.16 claims to support monotonic timestamps. I
couldn't figure out however, how they are supposed to work. From the
sources I only could figure out that they are enabled if a) the libc
knows CLOCK_MONOTONIC a) the kernel supports CLOCK_MONOTONIC, b) the
ALSA kernel code support timestamps this way. That's at least how I
read this code from pcm_hw.c:

<snip>
#if defined(HAVE_CLOCK_GETTIME) && defined(CLOCK_MONOTONIC)
        if (SNDRV_PROTOCOL_VERSION(2, 0, 9) <= ver) {
                struct timespec timespec;
                if (clock_gettime(CLOCK_MONOTONIC, &timespec) == 0) {
                        int on = SNDRV_PCM_TSTAMP_TYPE_MONOTONIC;
                        if (ioctl(fd, SNDRV_PCM_IOCTL_TTSTAMP, &on) <
                        0) {
                                ret = -errno;
                                SNDMSG("TTSTAMP failed\n");
                                return ret;
                        }
                        monotonic = 1;
                }
        }
#endif
          else if (SNDRV_PROTOCOL_VERSION(2, 0, 5) <= ver) {
                int on = 1;
                if (ioctl(fd, SNDRV_PCM_IOCTL_TSTAMP, &on) < 0) {
                        ret = -errno;
                        SNDMSG("TSTAMP failed\n");
                        return ret;
                }
        }
</snip>

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.

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!

There's a function missing that enables monotonic timestamps
explicitly, or at least one that can be used to query if they are
monotonic or not.

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.

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.

Lennart

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

Re: Monotonic timestamps

[Pieter Palmers]

Lennart Poettering wrote:
> Hey!

...

> 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!
> 
> There's a function missing that enables monotonic timestamps
> explicitly, or at least one that can be used to query if they are
> monotonic or not.
The clean solution would (IMHO) be to have ALSA provide a function to 
obtain 'current time', thereby making the timestamp system 
self-contained. Maybe it already does...

Greets,

Pieter

Re: Monotonic timestamps

[Jaroslav Kysela]

On Wed, 9 Apr 2008, Lennart Poettering wrote:

> Hey!

Hi,

> 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

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

Re: Monotonic timestamps

[Lennart Poettering]

On Thu, 10.04.08 09:03, Pieter Palmers (pieterp@joow.be) wrote:

> > 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!
> > 
> > There's a function missing that enables monotonic timestamps
> > explicitly, or at least one that can be used to query if they are
> > monotonic or not.
> The clean solution would (IMHO) be to have ALSA provide a function to 
> obtain 'current time', thereby making the timestamp system 
> self-contained. Maybe it already does...

This wouldn't help much since timestamps might also come from other
libraries. i.e. being able to relate timestamps from ALSA with
timestamps from the application itself is not enough. They also need
to be relatable to timestamps from other code, which might not
necessarily be linked against ALSA.

i.e. think of gstreamer that uses timestamps attached to each video
frame. Do you really expect gst to move their timestamp source over to
ALSA just because one of the plugins for gst supports ALSA?

Lennart

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

Re: Monotonic timestamps

[Lennart Poettering]

On Thu, 10.04.08 09:48, Jaroslav Kysela (perex@perex.cz) wrote:

Hi,

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

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

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.

Thanks,

Lennart

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

Re: Monotonic timestamps

[Pieter Palmers]

Lennart Poettering wrote:
> On Thu, 10.04.08 09:03, Pieter Palmers (pieterp@joow.be) wrote:
> 
>>> 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!
>>>
>>> There's a function missing that enables monotonic timestamps
>>> explicitly, or at least one that can be used to query if they are
>>> monotonic or not.
>> The clean solution would (IMHO) be to have ALSA provide a function to 
>> obtain 'current time', thereby making the timestamp system 
>> self-contained. Maybe it already does...
> 
> This wouldn't help much since timestamps might also come from other
> libraries. i.e. being able to relate timestamps from ALSA with
> timestamps from the application itself is not enough. They also need
> to be relatable to timestamps from other code, which might not
> necessarily be linked against ALSA.
> 
> i.e. think of gstreamer that uses timestamps attached to each video
> frame. Do you really expect gst to move their timestamp source over to
> ALSA just because one of the plugins for gst supports ALSA?

Let me put it another way: if some library provides timestamps, it 
should also provide a mechanism to obtain the current time. That way the 
  application is able to relate the timestamps to whatever clock it wants.

On the other hand, the "mechanism to obtain the current time" could 
equally well be "use CLOCK_MONOTONIC". In that sense your original post 
points out the issue, since obviously ALSA doesn't provide this info.

Never mind the noise.

Pieter

Re: Monotonic timestamps

[Jaroslav Kysela]

On Thu, 10 Apr 2008, Lennart Poettering wrote:

> On Thu, 10.04.08 09:48, Jaroslav Kysela (perex@perex.cz) wrote:
> 
> Hi,
> 
> > > 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:
> 
> <snip>
> 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.
> </snip>

Thanks for this link. But in 2.6 linux kernel, there is only system 
start-up time initializer for CLOCK_MONOTONIC, so the check is not so 
heuristics. Anyway, I added these functions to ALSA API, so you can remove 
timestamp / rewind notes from your list:

+int snd_pcm_hw_params_is_monotonic(const snd_pcm_hw_params_t *params);
+int snd_pcm_hw_params_can_forward(const snd_pcm_hw_params_t *params);
+int snd_pcm_hw_params_can_rewind(const snd_pcm_hw_params_t *params);

Also note, that forward/rewind returns always 1 for current alsa-lib, 
because rewind was implemented in the dmix plugin. But I can imagine, that 
this check can be required for some compressed streams.

					Jaroslav

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

Re: Monotonic timestamps

[Lennart Poettering]

On Fri, 11.04.08 14:16, Jaroslav Kysela (perex@perex.cz) wrote:

> > 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.
> > </snip>
> 
> Thanks for this link. But in 2.6 linux kernel, there is only system 
> start-up time initializer for CLOCK_MONOTONIC, so the check is not so 
> heuristics. 

Uh, but they might change this at any time in accordance with the specs.

> Anyway, I added these functions to ALSA API, so you can remove 
> timestamp / rewind notes from your list:
> 
> +int snd_pcm_hw_params_is_monotonic(const snd_pcm_hw_params_t *params);

Awesome, just what I need. /me crosses another item of the list.

> +int snd_pcm_hw_params_can_forward(const snd_pcm_hw_params_t *params);
> +int snd_pcm_hw_params_can_rewind(const snd_pcm_hw_params_t
> *params);

Hmm, I am not sure if this function this way is really such a good
idea. For example, for the PA backend for libasound/ioplug there might
be part of the delay buffer that can be rewound and part of the buffer
that cannot. Just think of an RTP output device. The part of the
buffer that is maintained on the sending side might be rewindable. But
as soon as the audio data entered the network, it might not be
rewindable anymore, although that network "buffer" will still
contribute to the latency.

I'd prefer some API that can tell me how much of the data actually is
rewindable. For hw devices this would return the same size as the
buffer size. For others it might return something smaller, and 0 for
devices that do not support rewinding at all.

Since PA mostly will only run on hw devices _can_forward() is probably
good enough for my purposes, though.

> Also note, that forward/rewind returns always 1 for current alsa-lib, 
> because rewind was implemented in the dmix plugin. But I can imagine, that 
> this check can be required for some compressed streams.

I assume for most of ioplug it will not return 1, right?

Thanks a lot,

Lennart

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

Re: Monotonic timestamps

[Jaroslav Kysela]

On Fri, 11 Apr 2008, Lennart Poettering wrote:

> > +int snd_pcm_hw_params_can_forward(const snd_pcm_hw_params_t *params);
> > +int snd_pcm_hw_params_can_rewind(const snd_pcm_hw_params_t
> > *params);
> 
> Hmm, I am not sure if this function this way is really such a good
> idea. For example, for the PA backend for libasound/ioplug there might
> be part of the delay buffer that can be rewound and part of the buffer
> that cannot. Just think of an RTP output device. The part of the
> buffer that is maintained on the sending side might be rewindable. But
> as soon as the audio data entered the network, it might not be
> rewindable anymore, although that network "buffer" will still
> contribute to the latency.
> 
> I'd prefer some API that can tell me how much of the data actually is
> rewindable. For hw devices this would return the same size as the
> buffer size. For others it might return something smaller, and 0 for
> devices that do not support rewinding at all.

Ok, I got the idea. I've added snd_pcm_rewindable() and 
snd_pcm_forwardable() functions to alsa-lib.

> > Also note, that forward/rewind returns always 1 for current alsa-lib, 
> > because rewind was implemented in the dmix plugin. But I can imagine, that 
> > this check can be required for some compressed streams.
> 
> I assume for most of ioplug it will not return 1, right?

The rewind/forward implementation in ioplug is actually broken, because it 
moves only internal pointer without notification to real external plugin. 

						Jaroslav

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