Fix for integer overflow in NetEq.

webrtc/common_audio/signal_processing/dot_product_with_scale.c

 /*
  *  Copyright (c) 2012 The WebRTC project authors. All Rights Reserved.
  *
  *  Use of this source code is governed by a BSD-style license
  *  that can be found in the LICENSE file in the root of the source
  *  tree. An additional intellectual property rights grant can be found
  *  in the file PATENTS.  All contributing project authors may
  *  be found in the AUTHORS file in the root of the source tree.
  */
 
@@ skipping 12 matching lines @@
     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;
 }
+
+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.

+}