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

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


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

webrtc-linux-large-tests
webrtc-mac-large-tests

This change is so small so it is expected that the changes in the code being done could have caused it. Therefore I'd say it is fine and expected.

Closing this bug.

I cannot agree that the change is so small, it is 50%. But you know better.

Sorry, I probably should have been more verbose.
What I meant was that the absolute value of the changes was so small. You are definitely right that in percent it is high.

But you should take into account that the failing tests are the worst case call duration of the render side in the audio processing module when no processing at all is done. 

The code in the CL that caused this degradation reintroduces the resampling of a 48 kHz render signal to 16 kHz that was present before March 17 so the call duration increase is not an increase if you look longer back in time.
And regardless of that, the increase is very small compared to the complexity in the module when actual processing is done.