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@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel