[alsa-devel] [PATCH v2] ALSA: hda/ca0132 - Update latency based on DSP state.

[Pierre-Louis Bossart]

> 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 
accounting methods.
-Pierre