On Thu, 10.04.08 09:48, Jaroslav Kysela (perex@xxxxxxxx) 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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
