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