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

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


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

webrtc-mac-large-tests

aluebs@, please, verify that this performance change is consistent with your expectations on the CL.

As expected, the complexity increases slightly only for the case of IntelligibilityEnhancer enabled, since it has to split on top of down-sampling in the reverse stream. Closing as working as intended.

One of the alerts is for the capture side also. When reviewing the CL I could not see why the capture side should be affected by the CL. Is that expected?

It shouldn't and I suspect it is only a side effect of how these tests measure performance. I have seen this dependencies between capture and render in previous performance issues.

I think that that then should motivate a reopening of the bug. The capture side complexity increases by 33 percent which is a lot and to me totally unexpected from this CL. 

Sorry, my bad, it was not 33 percent, but much less. But I still think it should be known why that happens.

It is totally unexpected, because it is unrelated to this CL. Because how the test and threading model is set up an increase in complexity in the render thread leaks into the capture metrics. I just corroborated by adding some artificial computations on the render thread and see the capture metrics go up as well. If anything we should file another bug towards the test itself or the APM threading model.

If you are confident that is the cause then please file a bug on the test (or the threading model if you rather think that is the causing issue). This test should not produce any false alarms according to what you describe.