AudioTrack getTimeStamp API usage in Exoplayer

[akatt-dolby]

Issue description

Usage of the AudioTrack getTimestamp API is not as per the Android AudioTrack API documentation.

Reproduction steps

When using ExoPlayer demo app, add debug log in updateTimestamp from the class AudioTrackUtilV19.

Link to API documentation

Below link is for your reference
https://developer.android.com/reference/android/media/AudioTrack.html#getTimestamp(android.media.AudioTimestamp)

Version of ExoPlayer being used

2.4.0

Detailed description about the query

As per the Android AudioTrack API documentation

getTimestamp

added in API level 19
boolean getTimestamp (AudioTimestamp timestamp)
Poll for a timestamp on demand.
If you need to track timestamps during initial warmup or after a routing or mode change, you should request a new timestamp periodically until the reported timestamps show that the frame position is advancing, or until it becomes clear that timestamps are unavailable for this route.
After the clock is advancing at a stable rate, query for a new timestamp approximately once every 10 seconds to once per minute. Calling this method more often is inefficient. It is also counter-productive to call this method more often than recommended, because the short-term differences between successive timestamp reports are not meaningful. If you need a high-resolution mapping between frame position and presentation time, consider implementing that at application level, based on low-resolution timestamps.
The audio data at the returned position may either already have been presented, or may have not yet been presented but is committed to be presented. It is not possible to request the time corresponding to a particular position, or to request the (fractional) position corresponding to a particular time. If you need such features, consider implementing them at application level.

The question is with regard to updateTimeStamp implementation in ExoPlayer, why is the AudioTrack API getTimeStamp called at every 500ms ? Can you please explain the reasons for the same.

Usage of the getTimeStamp can be found in AudioTrack class where a constant named MIN_TIMESTAMP_SAMPLE_INTERVAL_US which is set to 500000, it is this threshold expiry upon which updateTimeStamp gets called.

[ojw28]

We spoke to the platform team about this once, and the conclusion was that our usage is fine, despite not being strictly as documented. They basically didn't want apps continuously polling the method within a tight loop (e.g. every frame, or every 10ms), at which point the inefficiency of the calls becomes significant.

Having said that, it's possible we may adjust how we call this method in future. We're aware of a slight stuttering issue shortly after seeking, that may be due to the way in which we're calling it.

[ojw28]

Note: The stuttering issue is tracked by #3841.