timestamp update when no hw delta

timestamp update when no hw delta

[Henrik Eriksson]

Hi

I am looking into commit 3179f62001880e588e229db3006a59ad87b7792a
("ALSA: core: add .get_time_info"), which, if I understand the code
correctly, changed the behaviour of timestamps.  Before this change,
snd_pcm_update_hw_ptr0() just returned if the no_delta_check showed that
the hw_ptr had not changed.  With this change it will update the
timestamps before returning.

Was this intended, and if so does anyone have any insights to why?  The
original behaviour to not update the timestamps when the hw position has
not changed seems more correct to me, but I am new to this code.

Regards,
/henrik

Re: timestamp update when no hw delta

[Takashi Iwai]

On Tue, 10 Oct 2017 14:14:59 +0200,
Henrik Eriksson wrote:
> 
> Hi
> 
> I am looking into commit 3179f62001880e588e229db3006a59ad87b7792a
> ("ALSA: core: add .get_time_info"), which, if I understand the code
> correctly, changed the behaviour of timestamps.  Before this change,
> snd_pcm_update_hw_ptr0() just returned if the no_delta_check showed that
> the hw_ptr had not changed.  With this change it will update the
> timestamps before returning.
> 
> Was this intended, and if so does anyone have any insights to why?  The
> original behaviour to not update the timestamps when the hw position has
> not changed seems more correct to me, but I am new to this code.

Pierre is the best person to answer this, but AFAIK, the intention is
to allow more fine-grained timestamp, and it's finer than the sample
rate.  That is, you want to know the continuous (wallclock) time stamp
even between two PCM pulses, which allows more exact synchronization
of the PCM timeline and the system/network timeline.


thanks,

Takashi

Re: timestamp update when no hw delta

[Henrik Eriksson]

On Wed, Oct 25, 2017 at 08:30:55 +0200, Takashi Iwai wrote:
> On Tue, 10 Oct 2017 14:14:59 +0200,
> Henrik Eriksson wrote:
> > 
> > I am looking into commit 3179f62001880e588e229db3006a59ad87b7792a
> > ("ALSA: core: add .get_time_info"), which, if I understand the code
> > correctly, changed the behaviour of timestamps.  Before this change,
> > snd_pcm_update_hw_ptr0() just returned if the no_delta_check showed that
> > the hw_ptr had not changed.  With this change it will update the
> > timestamps before returning.
> > 
> > Was this intended, and if so does anyone have any insights to why?  The
> > original behaviour to not update the timestamps when the hw position has
> > not changed seems more correct to me, but I am new to this code.
> 
> Pierre is the best person to answer this, but AFAIK, the intention is
> to allow more fine-grained timestamp, and it's finer than the sample
> rate.  That is, you want to know the continuous (wallclock) time stamp
> even between two PCM pulses, which allows more exact synchronization
> of the PCM timeline and the system/network timeline.

Thank you.  With some more time to look into this, I am leaning towards
the new behaviour being closer to the definition of tstamp at
https://www.kernel.org/doc/Documentation/sound/designs/timestamping.rst,
which originated in the same patch series as the pcm_lib.c change.
But as far as I can tell it is an actual behaviour change for the
no_delta_check true case.  On devices that do not provide a granular
pcm hw pointer function, like using soc-generic-dmaengine-pcm with a
dmaengine that does not provide a residue count, it is very noticeable
since the pointer function will return 0.  In this case usermode will
also get an avail report of 0, so it cannot use that to count back from
tstamp.

Is there any way in ALSA to get a timestamp of a system clock from the
time the hwptr moved, similar to the behaviour before these changes?

Regards,
/henrik