Fix for integer overflow in NetEq.

webrtc/common_audio/signal_processing/dot_product_with_scale.c

Index: webrtc/common_audio/signal_processing/dot_product_with_scale.c
diff --git a/webrtc/common_audio/signal_processing/dot_product_with_scale.c b/webrtc/common_audio/signal_processing/dot_product_with_scale.c
index 1302d62541266fdc45b07576de5ff5026d69032f..c49e3fe95d31ff4ff01a716a4d54399b35d05a20 100644
--- a/webrtc/common_audio/signal_processing/dot_product_with_scale.c
+++ b/webrtc/common_audio/signal_processing/dot_product_with_scale.c
@@ -30,3 +30,24 @@ int32_t WebRtcSpl_DotProductWithScale(const int16_t* vector1,
 
   return sum;
 }
+
+int64_t WebRtcSpl_DotProductWithScale_64b(const int16_t* vector1,
+                                          const int16_t* vector2,
+                                          size_t length,
+                                          int scaling) {
+  int64_t sum = 0;
+  size_t i = 0;
+
+  /* Unroll the loop to improve performance. */
+  for (i = 0; i + 3 < length; i += 4) {
+    sum += (vector1[i + 0] * vector2[i + 0]) >> scaling;
+    sum += (vector1[i + 1] * vector2[i + 1]) >> scaling;
+    sum += (vector1[i + 2] * vector2[i + 2]) >> scaling;
+    sum += (vector1[i + 3] * vector2[i + 3]) >> scaling;
+  }
+  for (; i < length; i++) {
+    sum += (vector1[i] * vector2[i]) >> scaling;
+  }
+
+  return sum;

[kwiberg-webrtc, 2016/12/13 08:45:36]

IIUC, the reason for having the right shifts in this function is to avoid the
sum from overflowing. Now that you're accumulating in a 64-bit register, you can
no longer have overflow unless length is 2^33 or thereabouts. So it will be
faster and more accurate to not shift here, and just let the caller shift the
final sum afterwards. Unless you need to be bit compatible with the 32-bit
version, that is.

[ivoc, 2016/12/13 12:50:11]

You're right that it's more accurate to not shift here and shift afterwards.
However, that will result in larger values being calculated than previously
(less rounding downward of intermediate values -> larger outputs), and I don't
know what affect that has on the expand algorithm. I think the safest thing to
do is to keep the result the same as before.

+}