On 7/8/16 10:03 AM, Alan Young wrote:
On 07/06/16 07:44, Alan Young wrote:
I'll work on developing and testing a patch for consideration before coming back to the last. It will be easier to discuss the merits or otherwise of my proposal with a concrete, working patch to consider.
Well, it has been a few weeks but this is what I have come up with.
It is not perfect because of the issue noted in the comments but so far I have not been able to discover any downside. It many (most) cases, the reported delay (and audio_tstamp) is more accurate than it was before. In other cases there is no change.
I just looked at the code and I am probably missing something.
in update_delay() you apply a delta between the last timestamp and the current one and modify the runtime->delay.
Immediately after, in update_audio_tstamp() runtime->delay is used as well to compute audio_frames which in turn is used to find the audio_tstamp, on which another delta between current tstamp and last timestamp is applied.
Overall it looks like you are correcting twice for the same delay?
Even if this was correct, you would want to make sure the delta is positive to keep audio timestamps monotonous.