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

[Dylan Reid]

On Fri, Apr 5, 2013 at 10:20 AM, Pierre-Louis Bossart
<pierre-louis.bossart at linux.intel.com> wrote:
>
>> Thanks for the explanation Pierre, but I'm still a little confused.
>>
>> Does the timestamp represent the time the last sample was put in the
>> buffer or the time the last sample was rendered to the bus?
>>
>> Is the "current time" meant to be the timestamp that the next sample
>> sent will be rendered?  (timestamp + delay)
>
>
> When you query with snd_pcm_status(), you get all sort of information,
> including 2 timestamps. The 'regular' timestamp is just the system time
> (tsc) and the 'audio' timestamp is the time as reported by the audio
> hardware. This can be inferred by reading sample counters (# of samples
> pushed on the serial link) or wallclock counters, the wallclock is
> essentially identical but gives you a higher degree of precision. The audio
> time really needs to be taken at the last possible stage, not when you write
> into a buffer.
> The two timestamps can be used to find out what the drift is between the two
> time references (eg in PulseAudio)

I think I'm starting to understand this.  To go just a little bit deeper:

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

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

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.

> -Pierre
>