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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
