In PeerConnectionTestWrapper, put audio input on a separate thread.

In PeerConnectionTestWrapper, put audio input on a separate thread.

This will prevent it from blocking network input when it falls behind,
which is happening when running with ThreadSanitizer.

BUG=webrtc:4663
Committed: https://crrev.com/ee8c6d327357ecd2e17edede8d15f6e3893409a8
Cr-Commit-Position: refs/heads/master@{#9707}

[Taylor Brandstetter, 2015-07-18 00:21:37]

deadbeef@webrtc.org changed reviewers:
+ pthatcher@webrtc.org

[pthatcher1, 2015-07-23 17:13:19]

lgtm

https://codereview.webrtc.org/1236023010/diff/20001/talk/app/webrtc/test/peer...
File talk/app/webrtc/test/peerconnectiontestwrapper.cc (right):

https://codereview.webrtc.org/1236023010/diff/20001/talk/app/webrtc/test/peer...
talk/app/webrtc/test/peerconnectiontestwrapper.cc:84:
media_input_thread_.get());
I'd call it audio_capture_thread_ until we do something else with it.

[Taylor Brandstetter, 2015-07-24 02:52:37]

Hi Peter; could you review again when you get around to it? I changed a couple
more things.

1. Instead of using a thread passed into it, I'm having FakeAudioCaptureModule
create and own its own thread. This is necessary because I realized I can't
assume "Thread::Clear" guarantees no more messages will be dispatched. And
"Thread::Send" (what was used before) can't be used because it enters the
calling thread's socket server "Wait", which is a deadlock risk TSan correctly
identified. Also, every real audio device class creates its own thread in a
similar manner, so it seems sensible for the fake audio device class to do so as
well.

2. There were some members in webrtc::voe::Channel that weren't being protected
by a mutex. Looks like TSan only catches this occasionally (but that's ever more
the reason to fix it, I assume).

[pthatcher1, 2015-07-24 09:04:09]

lgtm if you pull the voice engine part into its own CL (you can submit the rest
if it doesn't cause the TSAN bot to fail)

https://codereview.webrtc.org/1236023010/diff/140001/webrtc/voice_engine/chan...
File webrtc/voice_engine/channel.h (right):

https://codereview.webrtc.org/1236023010/diff/140001/webrtc/voice_engine/chan...
webrtc/voice_engine/channel.h:278: CriticalSectionScoped
cs(&video_sync_critsect_);
Can you put these in a separate CL and have Tina's team review it?

[Taylor Brandstetter, 2015-07-24 19:34:54]

On 2015/07/24 09:04:09, pthatcher1 wrote:
> lgtm if you pull the voice engine part into its own CL (you can submit the
rest
> if it doesn't cause the TSAN bot to fail)
> 
>
https://codereview.webrtc.org/1236023010/diff/140001/webrtc/voice_engine/chan...
> File webrtc/voice_engine/channel.h (right):
> 
>
https://codereview.webrtc.org/1236023010/diff/140001/webrtc/voice_engine/chan...
> webrtc/voice_engine/channel.h:278: CriticalSectionScoped
> cs(&video_sync_critsect_);
> Can you put these in a separate CL and have Tina's team review it?

Ok; I'll put them in a separate CL. I can't submit this one until I submit the
other one though, because it does cause the TSan bot to occasionally fail.

[Taylor Brandstetter, 2015-08-13 19:23:26]

The CQ bit was checked by deadbeef@webrtc.org

[commit-bot: I haz the power, 2015-08-13 19:23:41]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1236023010/140001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1236023010/140001

[commit-bot: I haz the power, 2015-08-13 19:24:43]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-08-13 19:24:44]

Try jobs failed on following builders:
  android_gn_rel on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/android_gn_rel/builds/5048)
  ios_arm64 on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/ios_arm64/builds/3805)
  linux on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/linux/builds/8983)
  linux_asan on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/linux_asan/builds/8751)
  mac_x64_gn on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/mac_x64_gn/builds/3457)

[Taylor Brandstetter, 2015-08-13 20:44:27]

The CQ bit was checked by deadbeef@webrtc.org

[Taylor Brandstetter, 2015-08-13 20:44:27]

The patchset sent to the CQ was uploaded after l-g-t-m from pthatcher@webrtc.org
Link to the patchset: https://codereview.webrtc.org/1236023010/#ps160001 (title:
"resolving patch conflicts due to splitting this CL")

[commit-bot: I haz the power, 2015-08-13 20:44:40]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1236023010/160001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1236023010/160001

[commit-bot: I haz the power, 2015-08-13 21:27:22]

Committed patchset #9 (id:160001)

[commit-bot: I haz the power, 2015-08-13 21:27:32]

Patchset 9 (id:??) landed as
https://crrev.com/ee8c6d327357ecd2e17edede8d15f6e3893409a8
Cr-Commit-Position: refs/heads/master@{#9707}