Added option to specify a maximum file size when recording an AEC dump.

webrtc/modules/audio_processing/audio_processing_impl.h

Index: webrtc/modules/audio_processing/audio_processing_impl.h
diff --git a/webrtc/modules/audio_processing/audio_processing_impl.h b/webrtc/modules/audio_processing/audio_processing_impl.h
index bf29bf36332003bb62bbae0cededa3a500fe1db0..98f712c6328b676b8840473cc8eade6a62c8d69f 100644
--- a/webrtc/modules/audio_processing/audio_processing_impl.h
+++ b/webrtc/modules/audio_processing/audio_processing_impl.h
@@ -103,7 +103,10 @@ class AudioProcessingImpl : public AudioProcessing {
   int delay_offset_ms() const override;
   void set_stream_key_pressed(bool key_pressed) override;
   int StartDebugRecording(const char filename[kMaxFilenameSize]) override;
+  int StartDebugRecording(const char filename[kMaxFilenameSize],

[the sun, 2015/10/26 10:37:20]

I think it makes sense to keep just the interface with a given size here as
well.

[ivoc, 2015/11/05 13:14:46]

Done.

+                          int max_log_size_bytes) override;
   int StartDebugRecording(FILE* handle) override;
+  int StartDebugRecording(FILE* handle, int max_log_size_bytes) override;
   int StartDebugRecordingForPlatformFile(rtc::PlatformFile handle) override;
   int StopDebugRecording() override;
   void UpdateHistogramsOnCallEnd() override;
@@ -174,6 +177,10 @@ class AudioProcessingImpl : public AudioProcessing {
 
   // Serialized string of last saved APM configuration.
   std::string last_serialized_config_;
+
+  // Number of bytes that can still be written to the log before the maximum
+  // size is reached, a value of -1 indicates that no limit is used.
+  int nr_bytes_left_for_log;

[kwiberg-webrtc, 2015/10/25 02:29:12]

Split comment into separate sentences at the comma. And underscore at the end of
the name.

Oh, and using int means that you can't give a limit larger than 2 GB - 1 byte.
Probably not an immediate concern, but probably worth fixing now anyway while
it's easy.

[hlundin-webrtc, 2015/10/30 08:02:21]

Yes, and in general, variables dealing with number of bytes, indices, and counts
should be size_t. But I do realize you get a problem with the semantics for not
setting a limit. Let's discuss offline.

[kwiberg-webrtc, 2015/10/30 09:53:21]

Variables dealing with number of bytes, indices, and counts *in RAM* should be
size_t. For counting the same things *on disk*, use int64_t or uint64_t
(opinions vary on which is the right one; either one will work just fine).
Otherwise, 32-bit systems won't be able to handle files larger than 4 GB.

[hlundin-webrtc, 2015/10/30 09:59:14]

Ack. I stand corrected.

[ivoc, 2015/11/05 13:14:46]

I went for int64_t, hope that's okay.

 #endif
 
   // Format of processing streams at input/output call sites.