Similar in  issue 853498 .

Running a single story: video.html.src.tulip2.vp9.webm.Regular.3G
https://pinpoint-dot-chromeperf.appspot.com/job/12fa8825240000
medians: 579 477 436
means: 979 756 740

Rerun with the same story but a wider range:
https://pinpoint-dot-chromeperf.appspot.com/job/12fde2dd240000
medians: 1291 762
means: 1447 1173

When running the entire benchmark:
https://pinpoint-dot-chromeperf.appspot.com/job/14ad7af7240000
medians: 331 before regression, 378 after
means: 341 before regression, 417 after

Can someone from Chrome media team take a look please?

Probably has to do with audio output caching, not sure we can do anything about this. 

Dale, where is the audio output cache? I think we would like Telemetry to be able to clear all the caches necessary to have consistent results.

I spoke with Dale. Conversation notes: 

This bug is likely audio-related because both of the above media files play audio, and one of then does not have any video in it (the .wav file).

Chrome should be restarting between each run, and we *should* be clearing Chrome's various caches between runs. One thing to check for this bug is whether we are doing all of that successfully. One specific thing to check is the cache for Olka's new AudioService.

However, it is likely that we are clearing all of Chrome's caches successfully. If that is the case, then this could be related to some windows audio service that is caching the audio. If we restart the windows audio service (audiodg.exe), then it might fix this issue. We can also see if this issue reproduces on platforms other than Windows as a clue.