Hi Pierre,
Thanks for your continued engagement on this thread.
On 01/08/16 22:56, Pierre-Louis Bossart wrote:
On 7/20/16 1:59 AM, Alan Young wrote:
Yes, that could be true - there could be some jitter - but I think it will still result in more accurate results. Note that the adjustment to the reported audio_tstamp will only occur for the AUDIO_TSTAMP_TYPE_DEFAULT case and when the platform has not updated the (hw_ptr) position outside of the interrupt callback independent of whether the BATCH flag is used.
There is actually an argument for being less restrictive. Hardware platform updates to position, where they happen outside of an interrupt, may (generally will) be less accurate than the update mechanism that I propose because such position updates are mostly restricted to the level of DMA residue granularity, which is relatively coarse (usually).
I am not hot on changing a default behavior and end-up with platforms getting worse results and some getting better.
I am not sure that any platforms would get worse results (notwithstanding the jitter point above). Some would get better results.
It'd really be better if you used a new timestamp (I added the LINK_ESTIMATED_ATIME that isn't used by anyone and could be reclaimed) and modified the delay estimation in your own driver rather than in the core.
Well, I'm not looking at a single driver here. I am looking at several that use large parts of the common soc framework in various ways.
I'll look at LINK_ESTIMATED_ATIME and see if I could adopt that. I'm not sure how much it will help with the delay calculation but I suspect that the right answer could be deduced.
Note: For my application, I only actually care about the changes implemented using update_delay(). The refinement to update_audio_tstamp() just seemed to me to be part of the same issue. If the update_audio_tstamp() change is considered too controversial then I'd be happy to drop it.
if you change the delay by default then it changes the audio timestamp as well, not sure how you can isolate the two parts.
It only changes the audio timestamp if the user requests that the delay be included in it.
Stepping back for a moment, the delay calculation essentially consists of two parts:
1. How much data is still in the ring buffer. 2. How much data has been removed from the ring buffer but not yet played out.
In many respects it is artificial to separate these but that is what the API does.
In some cases the first factor is dominant, because DMA is consuming the buffer and one has - at the very best - only coarse-grained data about the position at any moment. It is unlikely ever to be sample-position accurate and, for most platforms, is much poorer.
In some cases the second factor is dominant because some data has been taken from the ring buffer and is then in some other significant size buffer. USB is a good example and, in that case, one can see that the generic driver does indeed used an elapsed-time calculation to generate (estimate) the delay report.
The more that I think about it the more it seems to me that using a time-based estimate for position (hw_ptr), outside of an interrupt callback, will always be more accurate than that returned by substream->ops->pointer(). Perhaps the results of that call should simply be ignored outside an interrupt callback - the call not even made, so as not to pollute the estimate with changed delay data.
Alan.