[alsa-devel] [PATCH v2] ALSA: hda/ca0132 - Update latency based on DSP state.
dgreid at chromium.org
Fri Apr 5 23:44:48 CEST 2013
On Fri, Apr 5, 2013 at 2:24 PM, Pierre-Louis Bossart
<pierre-louis.bossart at 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
>>> delay will be off by a fixed amount. Correcting the wallclock value and
>>> substracting the codec delay in azx_get_wallclk() would realign
>> 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.
More information about the Alsa-devel