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.