tiwai at suse.de
Mon Jan 7 16:27:02 CET 2008
At Mon, 7 Jan 2008 16:21:55 +0100,
Lennart Poettering wrote:
> On Mon, 07.01.08 12:10, Takashi Iwai (tiwai at suse.de) 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
> Maybe by adding two new time stamp modes, changeble via
> 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.
More information about the Alsa-devel