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