I'm away from my main desk, but I'll let this run over the weekend and check the sync. 

Is the app simply loading whole file videos (e.g. src=foo.mp4)? When you transition between different content, are you making a new video element? 

I recently added some debug logging to chrome://media-internals to detect bad audio timestamps, but this isn't available in version 51. Is it possible for you to load a developer channel build onto your box and then report to us the contents of chrome://media-internals once you've reproduced the issue? Make sure your chrome://version is 53.0.2784.3 or higher.

How to switch to dev channel:
https://support.google.com/chromebook/answer/1086915?hl=en

To answer your questions the app loads the whole video and waits for the complete event. Then it will create a new video element and once the new video start playing, the app destroys the old one. And it keeps repeating indefinitely.

I will also set up a test on the dev channel and provide the requested info early next week.

Interesting. Making a new video element every time should completely reset the audio clock we use for AV sync. Have you found any work arounds (short of restarting the app) that fix the sync?

Dale, any theories? 

With the a new video element every time it would have to browser side or something with pulse? We know from past experience* that the occasional transient error in the delay value can't accumulate in the audio clock. But I suppose its possible that the delay values we use at each render could be increasingly bad if they increasingly drift from the real OS values... I don't know though - its a whacky theory.

*https://bugs.chromium.org/p/chromium/issues/detail?id=586540#c9

To be clear, are you saying this works on desktop Chrome, but does not work on the Chromebox?

On Chrome Desktop we were not able to replicate but that may be due to resources. PCs tend to have a lot more RAM then the Chromeboxes. We also saw a difference between the Asus Chromebox(2GB RAM) and the AOpen Chromebox(4GB RAM). It only takes ~8 hours for the issue to be present on Asus vs ~20 hours on AOpen. At first we thought that each manufacturer provided their own codec which would account for the difference but it is possible that it is memory related.

Also I just received more information from our testers. It looks like the issue is ONLY present over HDMI. If we connect headphones to the audio port on the Chromeboxes the issue is not present.

Possibly something in CrOS audio stack then.

chinyue, Can you take a look?  Maybe we should have a test that can detect latency drift.  If it's a small amount that adds up, it should be detectable on a shorter time scale.

What was the audio device used for output? THe original report mentioned 'Chromebox' so I'd like to know if it was connected to HDMI, USB, or 3.5mm jack audio output?

note: we have A/V unsync issue reported on a few USB DAC/headsets.

The audio sync problem is present of HDMI. If we use the 3.5mm audio jack the issue is not present.

Support this all progress 

Using the app from https://www.dropbox.com/s/eudpm92kg2p99m5/asusvideotest7.crx?dl=0 with USB headset(Logitech G930, reported in  issue 588070  ) I am able to reproduce this issue.

I write a script to poll output buffer level continuously for 3 hours so far to track the max level:

Increase from 1280 to 2304
Increase from 2304 to 2928
Increase from 2928 to 3056
Increase from 3056 to 3824
Increase from 3824 to 3840
Increase from 3840 to 4352  <-- 1 hour
Increase from 4352 to 4720
Increase from 4720 to 4848
Increase from 4848 to 4864
Increase from 4864 to 5744
Increase from 5744 to 6512
Increase from 6512 to 6640
Increase from 6640 to 6656
Increase from 6656 to 7536
Increase from 7536 to 8304
Increase from 8304 to 9328
Increase from 9328 to 9984  <-- 3 hours
Increase from 9984 to 10864
Increase from 10864 to 11008

Output audio latency is directly affected by the buffer level. The rate estimator in CRAS reports device rate 48000.384 and adjusted the stream fetch period accordingly. I'll investigate why this doesn't help controlling the buffer level.

I figured out what is happening. Rate estimator works as expected and shouldn't be blamed, it's the new stream added causing buffer level to grow and eventually cause high latency.

This app basically plays a bunch of trailer clips and repeating. From CRAS's perspective it works like:

stream1 added
stream2 added
stream1 removed
stream3 added
stream2 removed
stream4 added
stream3 removed
...
stream-(N+1) added
stream-N removed

and the buffer level could drift at when a new stream added.
I'm working on a possible fix, will do some more testing and post the result here.

M53 should have this fixed.