Split from  issue 263654 :

https://bugs.chromium.org/p/chromium/issues/detail?id=263654#c72
Hm, I had the wrong version written down, it was of course the 51 Dev version, 51.0.2681.4.

So the fix should be there?  In that case, it doesn't really seem to make a very large impact.  I've got a test on http://fanoli01.itek.norut.no/Analysis/test.html - which plots the progress of currentTime compared to performance.now() (normalized for playback speed 1).  In an ideal world, you'd see a horizontal line, Chrome 51 has changed from earlier versions of course.  You can see some versions (not so many on Android) on http://fanoli01.itek.norut.no/Analysis/results.html  (use a wide browser...)

Importantly, the plot uses currentTime as reported immediately after a timechange event.  This is what gives us better accuracy in other browsers. Perhaps it is not really fresh, or compensated for before the event is triggered?

The flatter the line, the better we can synchronize it.  Please feel free to use the test, or if it fails to provide sufficient information, don't hesitate to ask!

https://bugs.chromium.org/p/chromium/issues/detail?id=263654#c74
http://fanoli01.itek.norut.no/Analysis/test2.html uses requestAnimationFrame instead - even though running getAnimationFrame back-to-back swamps everything to bits.  I've set it on a timer (after 200ms getAnimationFrame is requested).  It looks quite similar for audio at least, not at all even.  The basic thing the test does is:

* on first currentTime update (or query), remember performance.now() as startTime
* on each subsequent update, calculate the diff as elem.currentTime - (performance.now() - startTime)/1000 

One would expect that elem.currentTime is perfectly linear to performance.now() if it is calculated on each request.  The plots I get are not.  I made the trivial one at http://fanoli01.itek.norut.no/test/ if you want to take a look at it.