snd_pcm_status_get_tstamp()

snd_pcm_status_get_tstamp()

[Lennart Poettering]

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

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: snd_pcm_status_get_tstamp()

[Takashi Iwai]

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

Re: snd_pcm_status_get_tstamp()

[Lennart Poettering]

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

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: snd_pcm_status_get_tstamp()

[Takashi Iwai]

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

Re: snd_pcm_status_get_tstamp()

[Jaroslav Kysela]

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.