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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgyLfUuAkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgqI7GtQsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgyJO36AoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgyJWOrQsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgqNbqiAgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgqNyRtAkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgqNyRtAsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgqL2NoAoM


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

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

My change should only affect full_stack_video tests and are OS independent.

Since broken tests are audio tests I believe commit by henrika@ may be the main culprit, as it affects audio processing.

hlundin@: what does these tests measure?

My CL does not touch the audio path at all. It only moves some stat calculations used for logging
from a task queue into audiocallbacks. And the calculations are trivial (only counters).

In addition, my changes are platform agnostic and should have the same effect on all platforms if any effect existed.

Not sure where to go from here.

hlundin@: my CL landed in 16429 and judging from the graph that is after the jump. Do you agree?

hlundin@: if I speculatively revert my change. Would that show up directly in the perf tool bot?

Henrika@: From what I see, you introduced some locks and stats calculations in the audio device buffer. This might cause change in the tests. Especially, if tests did not count logging time before. Since increase is not huge in absolute values (in some tests its about 1us), it may not be a regression at all but just change in the way metrics are calculated because some code now is executed in the different thread.

Re #5: Yes, a speculative revert would show up pretty soon. Probably within hours.

I have committed a revert here:

https://codereview.webrtc.org/2684913003/

Please note that my change should only improve things since I have shown with profiling that the old code added overhead by calling PostTask on a task queue for each audio packet and that does come with a cost. I am surprised if the limited usage of locks here would have a negative impact.

Let's wait with all the details until the revert has landed. In any case, the intention of my change was to do good.

Henrik L: could you help me keep track and report back what the effect of my revert was. Thanks.

I will look at that. Thanks!

Cr-Commit-Position: refs/heads/master@{#16490}

https://chromium.googlesource.com/external/webrtc/+/fd8f102a847e7f8bd9c719ec6cc0b5818b626705

Henrik A: You are off the hook. It looks like your CL is not to blame. Feel free to re-land.

Reverted the revert. My CL is in again.

Should I revert my commit?
It makes even less sense, as it touches only video performance tests.

This could be related to https://bugs.chromium.org/p/chromium/issues/detail?id=690358.

Reverted my CL. Let's see.

Revert broke some other tests, so I relanded changes later. But it looks like it really was my commit.
I Will look into that further.

I found the broken tests in /webrtc/modules/audio_processing/audio_processing_performance_unnitest.cc

All my changes are contained within VideoQualityTest which is not referenced or used at all anywhere outside of video performance test. My changes are linked in the webrtc_perf_tests but aren't called at all. My code just couldn't cause regression unless there are some general problems like executable became too big or some other Mac magic.

solenberg@ could you please try to reproduce the bug?

Passing the hot potato to peah@, who wrote audio_processing_performance_unittest.cc.

Removing R-V-G label (was set upon bug filing because the bot was incorrectly configured as internal)

It does not make sense that these tests should fail due to that. But the size of the regression is so small so that it is not a concern.

Closing as WontFix.