Activate 'offload debug dump recordings from audio thread to TaskQueue'.

webrtc/media/engine/webrtcvoiceengine.h

Index: webrtc/media/engine/webrtcvoiceengine.h
diff --git a/webrtc/media/engine/webrtcvoiceengine.h b/webrtc/media/engine/webrtcvoiceengine.h
index d8466a0b414ace78f52236757e7324fd6d0b80ca..bbfec880f884186b20af5d0a22377e115f4b6c47 100644
--- a/webrtc/media/engine/webrtcvoiceengine.h
+++ b/webrtc/media/engine/webrtcvoiceengine.h
@@ -22,6 +22,7 @@
 #include "webrtc/base/constructormagic.h"
 #include "webrtc/base/networkroute.h"
 #include "webrtc/base/scoped_ref_ptr.h"
+#include "webrtc/base/task_queue.h"
 #include "webrtc/base/thread_checker.h"
 #include "webrtc/call/audio_state.h"
 #include "webrtc/call/call.h"
@@ -110,6 +111,9 @@ class WebRtcVoiceEngine final : public webrtc::TraceCallback  {
 
   void StartAecDump(const std::string& filename);
   int CreateVoEChannel();
+
+  rtc::TaskQueue low_priority_worker_queue_;

[the sun, 2017/05/22 22:38:00]

On some platforms this means we're adding yet another thread. What other options
have you considered?

[aleloi, 2017/05/23 11:05:49]

The file logging has to be done on *some* thread different from the real-time
one. Using a TaskQueue seemed the best solution, because

* using a custom (possibly existing) thread would require adding signaling
mechanisms for passing the thread down to APM/AecDump and communicating with it.
Compare the RTC event log:
https://cs.chromium.org/chromium/src/third_party/webrtc/logging/rtc_event_log...
* using a task queue could limit the total number of threads if the task queue
was passed from elsewhere. Other tasks could be run on the same task queue.

The current plan is to move the task queue in PeerConnectionFactory
created/destroyed by the signaling thread. This TQ could then be used for
similar tasks in different sub-modules (I think RTC event logging).

There is a dependent CL which attempts to do just that:
https://codereview.webrtc.org/2888303003. A few problems still remain, mainly
the case of using sub-components of WebRTC separately from
PeerConnectionFactory. That happens in internal projects.

[the sun, 2017/05/23 20:47:29]

Sorry about the confusion - that's not what I'm suggesting. Rather something
like what you reference below - sharing a thread/task queue for low prio tasks.

I'm looping in Danil and Tommi for thoughts on how TaskQueue is implemented -
IIRC in Chromium it is overridden with the Chromium impl - does that mean that
there is more thread pooling going on behind the scenes than is the case with
the pure WebRTC impl?

+
   webrtc::AudioDeviceModule* adm();
   webrtc::AudioProcessing* apm();
   webrtc::voe::TransmitMixer* transmit_mixer();