zqz/platform-external-webrtc
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

common_audio: Explicit cast in WebRtcSpl_NormW16 on ARM

Browse Source 
We currently hit asserts in AECM where the output of WebRtcSpl_NormW16() on armv7 is incorrect.
I've verified that it outputs -17 for negative values. Internally that means that clz returns 0 after a two's complement operation on a int16_t.
There is a mismatch between the int16_t input and otherwise 32 bit assumptions. Explicitly casting to int32_t makes the two's complement do the correct thing.

The CL also extends the unit tests by running through a larger set of values.

BUG=4486
TESTED=locally on Android Nexus 7 and trybots
R=aluebs@webrtc.org, kwiberg@webrtc.org

Review URL: https://webrtc-codereview.appspot.com/49549004

Cr-Commit-Position: refs/heads/master@{#8897}
This commit is contained in:
Bjorn Volcker
2015-03-30 23:38:28 +02:00
parent 0194d32873
commit bc46bf22e7
2 changed files with 10 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
webrtc/common_audio/signal_processing/signal_processing_unittest.cc
View File

@ -106,6 +106,11 @@ TEST_F(SplTest, InlineTest) {
EXPECT_EQ(15, WebRtcSpl_NormW16(-1));
EXPECT_EQ(0, WebRtcSpl_NormW16(WEBRTC_SPL_WORD16_MIN));
EXPECT_EQ(4, WebRtcSpl_NormW16(b32));
for (int ii = 0; ii < 15; ++ii) {
int16_t value = 1 << ii;
EXPECT_EQ(14 - ii, WebRtcSpl_NormW16(value));
EXPECT_EQ(15 - ii, WebRtcSpl_NormW16(-value));
}
EXPECT_EQ(0, WebRtcSpl_NormU32(0u));
EXPECT_EQ(0, WebRtcSpl_NormU32(0xffffffff));