Fix data race in AMP.

Fix data race in AMP.

R=aluebs@webrtc.org, aluebs-webrtc
BUG=516637
Committed: https://chromium.googlesource.com/external/webrtc/+/4bc66fc3879e7bd3fcd6f7dedf0c4bb35e88e66f

[mgraczyk, 2015-08-10 21:41:41]

The affected ProcessStream overload reads from apm's StreamConfig members. 
Without being protected by a mutex, that read could occur during a write to the
same members resulting in a race.

Right now this can't affect behavior because the overload subsequently writes
over all fields in both StreamConfigs. However, that could change in the future.

[aluebs-webrtc, 2015-08-10 22:11:26]

lgtm

[mgraczyk, 2015-08-10 22:26:47]

Committed patchset #1 (id:1) manually as
4bc66fc3879e7bd3fcd6f7dedf0c4bb35e88e66f (presubmit successful).

[Andrew MacDonald, 2015-08-11 18:56:35]

andrew@webrtc.org changed reviewers:
+ andrew@webrtc.org

[Andrew MacDonald, 2015-08-11 18:56:36]

https://codereview.webrtc.org/1279953003/diff/1/webrtc/modules/audio_processi...
File webrtc/modules/audio_processing/audio_processing_impl.cc (right):

https://codereview.webrtc.org/1279953003/diff/1/webrtc/modules/audio_processi...
webrtc/modules/audio_processing/audio_processing_impl.cc:492:
CriticalSectionScoped crit_scoped(crit_);
FYI: Looks like the webrtc mutexes are recursive, but it's still not great to be
locking this here and in the ProcessStream call below. I think it's OK since we
intend to remove this call.