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

[Pierre-Louis Bossart]

> 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.

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