[alsa-devel] Latency and timestamps
Heikki Lindholm
holindho at cs.helsinki.fi
Wed Nov 21 14:26:05 CET 2007
Takashi Iwai kirjoitti:
> At Mon, 19 Nov 2007 22:46:31 -0200,
> Claudio Matsuoka wrote:
>> Hi,
>>
>> I'm adding latency control to an application and didn't find much
>> documentation about the pcm status functions aside from a very brief
>> description and the latency.c example. What exactly are the "trigger
>> timestamp" and "now timestamp" returned by
>> snd_pcm_status_get_trigger_tstamp() and snd_pcm_status_get_tstamp()?
>
> The trigger_tstamp is the time-stamp at the last time the PCM status
> change occured. For example, when the PCM is really triggered to
> start, or stopped, or XRUN, etc. It won't be changed as long as the
> PCM status is kept.
>
> OTOH, the tstamp is the current timestamp (now). But, this value has
> a slightly different meaning when tstamp_mode is set to
> SND_PCM_TSTAMP_MMAP. Then it keeps the timestamp of the last period
> update time instead of the now.
I looked at the code and I'm not sure I understand the above "last
period update time" correctly. I'd like to think that MMAP timestamp is
updated by the driver interrupt handler when a new period arrives _and
only there_, but the code seems somewhat different:
- the timestamp is generated in snd_pcm_update_hw_ptr_pos
- snd_pcm_update_hw_ptr_pos is called by snd_pcm_update_hw_ptr_interrupt
- the driver interrupt updates the timestamp in snd_pcm_period_elapsed
BUT if the user calls snd_pcm_status
- snd_pcm_status calls snd_pcm_update_hw_ptr
- snd_pcm_update_hw_ptr calls snd_pcm_update_hw_ptr_pos
and therefore it seems that the timestamp is updated when calling
snd_pcm_status also, effectively making the timestamp a "now" timestamp
anyway.
-- Heikki Lindholm
More information about the Alsa-devel
mailing list