At Mon, 7 Jan 2008 16:21:55 +0100, Lennart Poettering wrote: > > On Mon, 07.01.08 12:10, Takashi Iwai (tiwai@xxxxxxx) wrote: > > > > The documentation for snd_pcm_status_get_tstamp() is not really > > > enlightening. After a call to snd_pcm_status() what data does the > > > tstamp field actually carry? Some kind of system clock timestamp when > > > the data in the status struct was valid, or some kind of sound card > > > clock timestamp that is relative to the point in time where the device > > > was opened/started? > > > > In the normal mode, it's the timestamp at the moment snd_pcm_status() > > is processed. OTOH, the trigger_tstamp is the time that the trigger > > callback was called (e.g. the stream starts / stops). > > The time is the system-wide time, equivalent with the normal > > gettimeofday(). > > So I figure this is always CLOCK_REALTIME? > > I am currently using CLOCK_MONOTONIC for most timekeeping in > PulseAudio. Would it be possible to add an API to ALSA to allow > getting those timestamps in CLOCK_MONOTONIC instead of CLOCK_REALTIME? CLOCK_MONOTONIC is already available in the newer version of ALSA-driver. But, the corresponding alsa-lib API isn't implemented yet. > Maybe by adding two new time stamp modes, changeble via > snd_pcm_sw_params_set_tstamp_mode()? > > Also, may I suggest to add the explanation you wrote above to the > doxygen docs? A patch is welcome :) That's not the part I've implemented, too. Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
