[alsa-devel] Monotonic timestamps
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, ×pec) == 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 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
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 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
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.
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
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.
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
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.
participants (3)
-
Jaroslav Kysela -
Lennart Poettering -
Pieter Palmers