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.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
