Consistent 30% improvement in audio mixer running time.
Consistent 30% improvement in audio mixer running time.

(Or, in less flattering terms, fixing a performance issue introduced
a few months ago by me).

In GN release mode (is_debug = false), the version of the mixer code
before this CL generated code that multiplied each sample (tens of
thousands/second for each input stream) with a floating point number.
This number is almost always exactly 1.0f. The only situation when it's
not 1 is when an audio steam is added or removed.

For one input stream early return leads to a 30% improvement of audio
mixing time profiled on x86-64 under a release build (is_debug = false,
enable_profiling, enable_full_stack_frames_for_profiling) with 16kHz and no
APM limiter. There can be up to 3 streams.

BUG=chromium:687502

Review-Url: https://codereview.webrtc.org/2659423002
Cr-Original-Commit-Position: 972c6d2dc6dd5efdad1377c0d224e03eb8f276f7@{#16396}
Cr-Mirrored-From: https://chromium.googlesource.com/external/webrtc
Cr-Mirrored-Commit: 4637b6afca431be8caf1d22151a2cbb2e86a33d5

Alkalyne/webrtctrunk,Alkalyne/webrtctrunk,Alkalyne/webrtctrunk,Alkalyne/webrtctrunk,Alkalyne/webrtctrunk,Alkalyne/webrtctrunk,Alkalyne/webrtctrunk,Alkalyne/webrtctrunk