[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