Update audio code to use size_t more correctly,

webrtc/modules/audio_coding/codecs/isac/main/source/bandwidth_estimator.h

Index: webrtc/modules/audio_coding/codecs/isac/main/source/bandwidth_estimator.h
diff --git a/webrtc/modules/audio_coding/codecs/isac/main/source/bandwidth_estimator.h b/webrtc/modules/audio_coding/codecs/isac/main/source/bandwidth_estimator.h
index 291687608256c2c1738d69b6a2536f407d224326..0704337f7df1bc675fbab439a4b1b2c05b2fd4aa 100644
--- a/webrtc/modules/audio_coding/codecs/isac/main/source/bandwidth_estimator.h
+++ b/webrtc/modules/audio_coding/codecs/isac/main/source/bandwidth_estimator.h
@@ -95,7 +95,7 @@ extern "C" {
       const int32_t frame_length,
       const uint32_t send_ts,
       const uint32_t arr_ts,
-      const int32_t pksize);
+      const size_t pksize);

[minyue-webrtc, 2015/07/31 14:10:14]

why not on frame_length as well? But anyways, back to the general question, what
factors decide whether to size_t or not?

[Peter Kasting, 2015/08/04 02:02:52]

According to the comments here, frame_length is in milliseconds, which unless
other factors intruded I would normally measure using an int, as opposed to
being, say, bytes, which should use a size_t.

[minyue-webrtc, 2015/08/04 07:31:50]

Fair enough

 
   /* Update receiving estimates. Used when we only receive BWE index, no iSAC data packet. */
   int16_t WebRtcIsac_UpdateUplinkBwImpl(