[alsa-devel] snd_pcm_status_get_tstamp()
Hi!
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?
Lennart
At Mon, 31 Dec 2007 17:53:40 +0100, Lennart Poettering wrote:
Hi!
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().
Takashi
On Mon, 07.01.08 12:10, Takashi Iwai (tiwai@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?
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?
Thanks,
Lennart
At Mon, 7 Jan 2008 16:21:55 +0100, Lennart Poettering wrote:
On Mon, 07.01.08 12:10, Takashi Iwai (tiwai@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 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
On Mon, 7 Jan 2008, Takashi Iwai wrote:
At Mon, 7 Jan 2008 16:21:55 +0100, Lennart Poettering wrote:
On Mon, 07.01.08 12:10, Takashi Iwai (tiwai@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 yet.
Right. I will do this.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
participants (3)
-
Jaroslav Kysela -
Lennart Poettering -
Takashi Iwai