On Fri, Apr 5, 2013 at 2:24 PM, Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com wrote:
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)?
Yes, correct.
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?
If wall clock is supported, audio timestamp doesn't account for codec delay If Wall clock is not suported, audio timestamp does account for codec delay with your patches.
Good, I get it, thanks for the education!
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.
My suggestion is that the audio timestamp always accounts for codec delays, which will allow you to track drift and track rendering time. Btw for capture wallclocks are disabled for now since we don't really know how to use them for digital inputs, and we really need to have a consistent behavior for capture and playback.
Sounds good, I'll take a look at adding the delay to the wallclock time as well.
-Pierre