All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=692445

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDguIDKsAoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgmMWXmwgM


Bot(s) for this bug's original alert(s):

webrtc-android-tests-nexus5
webrtc-mac-large-tests

WebRTC commit range for this change: https://chromium.googlesource.com/external/webrtc/+log/f6ddbe77cbc54c8e5c99a1e0f833d9a25868d26e..38cc1d6b31eff566651bc1d09b8a4e9093bcb90d

I am not sure which CL might cause this change, but I suspect it might be sakal@ one, but maybe it's nisse@.

I don't think it my CL because it only affects AppRTC Mobile.

My cl reorganizes rtp header parsing for video only. So it could have some effect on performance, but audio performance changes is a bit unexpected.
Looking back a week or two, the variation isn't out of the ordinary.

peah, can you add anything of the significance of these tests? Is a few us variations anything to worry about? They're not documented at 
https://sites.google.com/a/google.com/rtc-platform/test-engineering/performance-tests#TOC-What-Test-Metrics-Mean

Graphs look like they're back to values before this alert. So I don't think we need to spend any time on further investigation.