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

[Dylan Reid]

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