media/libraries
tonihei 0dc5ed19e2 Improve timestamp smoothing in AudioTrackPositionTracker
The position tracker has two different position sources,
getPlaybackHeadPosition and getTimestamp. Whenever we switch
between these sources, we smooth out the position differences
over a period of one second.

This has two problems:

 1. The smoothing duration is 1 sec regardless of the actual
    position difference. So for small differences, assuming
    the new timestamp is more correct, we needlessly keep
    the tracker with a position offset for longer. For large
    differences, the smoothing may result in an extremely
    large speedup (up to 5x in theory, for a max allowed diff
    of 5 seconds smoothed over a 1 second real time period).

    The solution to this issue is to adjust the smoothing
    period to the actual difference by using a maximum
    speedup/slowdown set to 10% at the moment. Smaller
    differences are corrected faster and larger differences
    are corrected in a slightly smoother way without speeding
    up drastically. We still need an upper bound though (set
    to 1 second difference) where plainly jumping to the correct
    position is likely a better user experience than having a lenghty
    smoothing.

 2. The smoothing is only applied when switching between position
    sources. That means any position drift or jump coming from the
    same source is always taken as it is without any smoothing. This
    is problematic for the getTimstamp-based position in particular
    as it is only sampled every 10 seconds.

    The solution to this problem is to entirely remove the condition
    that smoothing only happens when switching between position
    sources. Instead we can always check whether the position drift
    compared to the last known position is more than the maximum allowed
    speedup/slowdown of 10% and if so, start applying smoothing.

    This helps to smooth out the position progress at the start of
    playback and after resumption when we switch between the position
    sources and both sources are not super reliable yet and it also
    helps for unexpected jumps in the position of getTimestamp later
    on during playback.

PiperOrigin-RevId: 755348271
2025-05-06 06:36:10 -07:00
..
2024-11-04 04:16:39 -08:00