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