From 4637b6afca431be8caf1d22151a2cbb2e86a33d5 Mon Sep 17 00:00:00 2001 From: aleloi Date: Wed, 1 Feb 2017 03:43:31 -0800 Subject: [PATCH] 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-Commit-Position: refs/heads/master@{#16396} --- webrtc/modules/audio_mixer/audio_frame_manipulator.cc | 3 +++ 1 file changed, 3 insertions(+) diff --git a/webrtc/modules/audio_mixer/audio_frame_manipulator.cc b/webrtc/modules/audio_mixer/audio_frame_manipulator.cc index ff4c31e667..8aa0b5ce02 100644 --- a/webrtc/modules/audio_mixer/audio_frame_manipulator.cc +++ b/webrtc/modules/audio_mixer/audio_frame_manipulator.cc @@ -29,6 +29,9 @@ void Ramp(float start_gain, float target_gain, AudioFrame* audio_frame) { RTC_DCHECK(audio_frame); RTC_DCHECK_GE(start_gain, 0.0f); RTC_DCHECK_GE(target_gain, 0.0f); + if (start_gain == target_gain) { + return; + } size_t samples = audio_frame->samples_per_channel_; RTC_DCHECK_LT(0, samples);