[alsa-devel] [PATCH v2] ALSA: hda/ca0132 - Update latency based on DSP state.
pierre-louis.bossart at linux.intel.com
Fri Apr 5 19:20:26 CEST 2013
> Thanks for the explanation Pierre, but I'm still a little confused.
> Does the timestamp represent the time the last sample was put in the
> buffer or the time the last sample was rendered to the bus?
> Is the "current time" meant to be the timestamp that the next sample
> sent will be rendered? (timestamp + delay)
When you query with snd_pcm_status(), you get all sort of information,
including 2 timestamps. The 'regular' timestamp is just the system time
(tsc) and the 'audio' timestamp is the time as reported by the audio
hardware. This can be inferred by reading sample counters (# of samples
pushed on the serial link) or wallclock counters, the wallclock is
essentially identical but gives you a higher degree of precision. The
audio time really needs to be taken at the last possible stage, not when
you write into a buffer.
The two timestamps can be used to find out what the drift is between the
two time references (eg in PulseAudio)
In other words, if you add the codec delay, it's fine but it needs to be
accounted for in a symmetrical manner, otherwise the audio timestamp and
the delay will be off by a fixed amount. Correcting the wallclock value
and substracting the codec delay in azx_get_wallclk() would realign
More information about the Alsa-devel