Allow the RTP level indicator computation to work at any sample rate.
Break out the computation to a separate class, and call directly into
this from channel.cc rather than going through AudioProcessing. This
circumvents AudioProcessing's sample rate limitations.
We now compute the RMS over all samples rather than downmixing to a
single channel. This makes the call point in channel.cc easier, is
more "correct" and should have similar (negligible) complexity.
This caused slight changes in the RMS output, so the ApmTest.Process
reference has been updated. Snippet of the failing output:
[ RUN ] ApmTest.Process
Running test 4 of 12...
Value of: rms_level
Actual: 27
Expected: test->rms_level()
Which is: 28
Running test 5 of 12...
Value of: rms_level
Actual: 26
Expected: test->rms_level()
Which is: 27
Running test 6 of 12...
Value of: rms_level
Actual: 26
Expected: test->rms_level()
Which is: 27
Running test 10 of 12...
Value of: rms_level
Actual: 27
Expected: test->rms_level()
Which is: 28
Running test 11 of 12...
Value of: rms_level
Actual: 26
Expected: test->rms_level()
Which is: 27
Running test 12 of 12...
Value of: rms_level
Actual: 26
Expected: test->rms_level()
Which is: 27
BUG=3290
TESTED=Chrome assert is avoided and both voe_cmd_test and apprtc
produce reasonable printed out results from RMS().
R=bjornv@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/16459004
git-svn-id: http://webrtc.googlecode.com/svn/trunk/data@6056 4adac7df-926f-26a2-2b94-8c16560cd09d
1 file changed
