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

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


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

chromium-webrtc-rel-7

philipel@: Could this regression be related to your recent changes in the jitterbuffer?

Since it is on the ChromiumWebRTC bot and the WebRTC version did not change as the regression occurred I think this is due to some change in Chromium. 

Great point!
hta@: The recent variations in this metric seems to match rolls that include the CLs
https://codereview.chromium.org/2585733002
https://codereview.chromium.org/2651543002
https://codereview.chromium.org/2651183003

which relate to the landing, revert, and relanding of the H264 assembly code. Can this be related to that? I cannot see why audio_tx would be affected by that

It's possible that the saving in CPU due to faster encode left more CPU free to push audio packets through the pipeline (the change is an improvement). I note that variations are down too.

Closing as "minor change, looks beneficial, won't fix".