On 15/07/16 21:13, Pierre-Louis Bossart wrote:
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?
In update_audio_tstamp() it either usedruntime->delay, if runtime->audio_tstamp_config.report_delay is true, or applies a delta - not both.
Even if this was correct, you would want to make sure the delta is positive to keep audio timestamps monotonous.
Hmm, maybe. In what circumstances could the delay ever be negative?