tree e07c6f5ec6172b4a5c810ac3100f2701d3f04074
parent 1b794d56b72853fe2eecbea2c719886c44578ed8
author Karl Wiberg <kwiberg@webrtc.org> 1431418200 +0200
committer Karl Wiberg <kwiberg@webrtc.org> 1431418198 +0000

Fix race in AudioCodingModuleImpl::Add10MsData()

AudioCodingModuleImpl::Add10MsData() calls two private methods that
together do all the work: Add10MsDataInternal() and Encode(). They
each took locks internally in order to protect access to, among other
things, codec_manager_.

This turned out to be inadequate. Add10MsDataInternal() calls
codec_manager_.CurrentEncoder()->SampleRateHz() in order to be able to
resample the audio data to what the current encoder wants. When the
resampled data is fed to the encoder deep inside the Encode() call,
that sample rate must still be correct, but occasionally it wasn't,
which triggered a CHECK. (The specific test that failed was the
voe_auto_test subtest
CodecTest.OpusMaxPlaybackRateCannotBeSetForNonOpus, which changes the
current encoder while encoding is in progress.)

This CL solves the problem by covering all of
AudioCodingModuleImpl::Add10MsData() in a single critical section, so
that the sample rate obtained in Add10MsDataInternal() is guaranteed
to still be valid during the Encode() call.

BUG=4644
R=henrik.lundin@webrtc.org

Review URL: https://webrtc-codereview.appspot.com/52459004

Cr-Commit-Position: refs/heads/master@{#9174}