[Chromecast] If timestamps are continuously off, resync

On some SoMs it was observed that occasionally the timestamps obtained from the
AudioTrack are suddenly consistently off from their expected value. This is
different from just normal timestamp jitter which evens out over time. The
result is errors flooding the logs due to the way we handle this currently.

While jumping timestamps is certainly indicative of a bug in the audio HAL
driver, we should still handle this better and simply resync to the new offset.

Bug: internal b/77654451
Test: Ran on several different SoMs, verfied proper behaviors.

Change-Id: Ia12ad4980ac69e7b81ea498f8edc197b60bf5038
Reviewed-on: https://chromium-review.googlesource.com/1003994Reviewed-by: Kenneth MacKay <kmackay@chromium.org>
Commit-Queue: Chris Kuiper <ckuiper@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549920}

chromecast/media/cma/backend/android/java/src/org/chromium/chromecast/cma/backend/android/AudioSinkAudioTrackImpl.java

@@ -127,6 +127,9 @@ class AudioSinkAudioTrackImpl {
         STABLE, // Reference time exists and is updated regularly.
         RESYNCING_AFTER_UNDERRUN, // The AudioTrack hit an underrun and we need to find a new
                                   // reference timestamp after the underrun point.
+        RESYNCING_AFTER_EXCESSIVE_TIMESTAMP_DRIFT, // We experienced excessive and consistent
+                                                   // jitters in the timestamps and we should find a
+                                                   // new reference timestamp.
     }
 
     ReferenceTimestampState mReferenceTimestampState;
@@ -652,6 +655,8 @@ class AudioSinkAudioTrackImpl {
                                 + elapsedNsec(mTimestampStabilityStartTimeNsec) / 1000000 + "ms]");
                 break;
 
+            case RESYNCING_AFTER_EXCESSIVE_TIMESTAMP_DRIFT:
+            // fall-through
             case RESYNCING_AFTER_UNDERRUN:
                 // Resyncing happens after we hit an underrun in the AudioTrack. This causes the
                 // Android Audio stack to insert additional samples, which increases the reference
@@ -672,7 +677,8 @@ class AudioSinkAudioTrackImpl {
                 mRefNanoTimeAtFramePos0 = newNanoTimeAtFramePos0;
                 mReferenceTimestampState = ReferenceTimestampState.STABLE;
                 Log.i(mTag,
-                        "New stable timestamp after underrun [" + mTimestampStabilityCounter + "/"
+                        "New stable timestamp after underrun or excessive drift ["
+                                + mTimestampStabilityCounter + "/"
                                 + elapsedNsec(mTimestampStabilityStartTimeNsec) / 1000000 + "ms]");
                 break;
 
@@ -690,8 +696,12 @@ class AudioSinkAudioTrackImpl {
                     if (timeSinceLastGoodTstamp <= MAX_TIME_IGNORING_TSTAMPS_NSECS) {
                         return; // Ignore this one.
                     }
-                    // We ignored jittery timestamps for too long, let this one pass.
+                    // We ignored jittery timestamps for too long, restart sync logic.
                     Log.i(mTag, "Too many jittery timestamps ignored!");
+                    mLastTimestampUpdateNsec = NO_TIMESTAMP;
+                    mTimestampStabilityCounter = 0;
+                    mReferenceTimestampState =
+                            ReferenceTimestampState.RESYNCING_AFTER_EXCESSIVE_TIMESTAMP_DRIFT;
                 }
                 // Low-pass filter: 0.10*New + 0.90*Ref. Do integer math with proper rounding.
                 mRefNanoTimeAtFramePos0 =