On Mon, 05 Nov 2018 16:57:07 +0100,
Mike Brady wrote:
>
> > One another thing I'd like to point out is that the value given in the
> > patch is nothing but an estimated position, optimistically calculated
> > via the system timer. Mike and I had already discussion in another
> > thread, and another possible option would be to provide the proper
> > timestamp-vs-hwptr pair, instead of updating the timestamp always at
> > the status read.
>
> Agreed — that would give the caller the information needed to do the
> interpolation for themselves if desired.
And now I wonder whether the problem is still present with the latest
code. There was a (kind of) regression in this regard when we
introduced the fine-grained hardware timestamping, but it should have
been addressed by the commit 20e3f985bb875fea4f86b04eba4b6cc29bfd6b71
ALSA: pcm: update tstamp only if audio_tstamp changed
Could you double-check whether the tstamp field gets still updated
even if no hwptr (and delay) is changed?
thanks,
Takashi
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
