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

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=a4411e93148781845b06274767c12c7d64edb01fff0064af32b61911f24fb2d2


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

webrtc-mac-large-tests

Oh, it's echo detector, not echo canceler. Sorry for the noise Per :).

This change should not have any effect on this test, the CL probably causes a change in the binary size or something. I think we should remove this test, since it is pretty unreliable and flaky, and it triggers on a lot of unrelated CLs (like this one), and I think we've never found an actual bug by using it. 

The only way how this CL may affect the metrics is what echo detector is relying on the capture ntp timestamps of audio frames and slight change in them (they should be more reliable now) causes different results.

But I think it's very unlikely, as the first spike in the graphs is corresponding to chromium roll and my Cl in question causes second drop only on the second graph. On the first graph the second drop corresponds to another my CL, completely unrelated to audio.