On Fri, Apr 5, 2013 at 10:20 AM, Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com wrote:
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)
I think I'm starting to understand this. To go just a little bit deeper:
Is the 'audio' timestamp the one calculated in snd_pcm_update_hw_ptr0, based on either the hardware or the delay (INFO_HAS_WALL_CLOCK)?
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.
Would this problem manifest on systems that don't support wall clock? Because the time based on delay will contain the codec delay?
There are two distinct use cases:
Wanting to know how the audio clock is drifting with respect to the system clock. (don't care about codec delay) Wanting to know when a sample will be rendered for AEC or A/V sync. (codec delay critical)
Can we keep them from affecting one another? This seems possible if the timestamp and delay are reported separately.
-Pierre