382c0c209d
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@6056 4adac7df-926f-26a2-2b94-8c16560cd09d |
||
|---|---|---|
| .. | ||
| audio_processing | ||
| common_video/jpeg | ||
| rtp_rtcp | ||
| voice_engine | ||