On Thu, 10 Apr 2008, Lennart Poettering wrote: > 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> 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@xxxxxxxx> Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel