On 6/6/16 4:42 AM, Alan Young wrote:
On 06/06/16 09:34, Takashi Iwai wrote:
On Sun, 05 Jun 2016 12:33:20 +0200,
Alan Young wrote:
Regardless of what value of DMA_RESIDUE_GRANULARITY_xxx that a driver
claims to support, it is not really defined how fine a burst might
be. So the end result is, from the point of view of audio, that the
resulting position obtained by the pointer() call is pretty
inaccurate. Hence my proposal to attempt to improve the accuracy of
the pcm_status() result given the above constraints.
Well, the subject appears misleading. What you want isn't the audio
timestamp accuracy. From API POV, the accurate position is calculated
via the (additional) delay. So, what you want is rather the accurate
position delay accounting, and the audio timestamp is merely one of
the ways to achieve that.
Well, yes, you could put it that way. Whether an accurate delay,
combined with the associated timestamp, or an accurate audio delay, I
would have the data needed to track audio drift from wallclock time.
I probably need more coffee but how is this patch helping track audio v.
wallclock drift? The additional precision is based on wallclock deltas...
See my response to Raymond for more detail.
Alan.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
