862681 - Android JNI audio device multi-thread problem

Status: RESOLVED INCOMPLETE

(Core :: WebRTC: Audio/Video, defect)

Description

[Chiajung Hung [:chiajung]]

This is a follow bug of Bug 825112

We found some member data access in Android audio_device do not protected by Mutex in Bug 825112.

Here is a list for problematic function/variable:
  AudioDeviceAndroidJni::Recording() : _recording
  AudioDeviceAndroidJni::PlayoutDelay() : _delayPlayout
  AudioDeviceAndroidJni::RecordingDelay : _delayRecording
  AudioDeviceAndroidJni::Playing() : _playing
  AudioDeviceAndroidJni::PlayoutBuffer() : _delayPlayout
  AudioDeviceAndroidJni::PlayoutWarning() : _playWarning
  AudioDeviceAndroidJni::PlayoutError() : _playError
  AudioDeviceAndroidJni::RecordingWarning() : _recWarning
  AudioDeviceAndroidJni::RecordingError() : _recError
  AudioDeviceAndroidJni::ClearPlayoutWarning() : _playWarning
  AudioDeviceAndroidJni::ClearPlayoutError() : _playError
  AudioDeviceAndroidJni::ClearRecordingWarning() : _recWarning
  AudioDeviceAndroidJni::ClearRecordingError() : _recError
  AudioDeviceAndroidJni::InitSampleRate() : _samplingFreqIn, _samplingFreqOut
  AudioDeviceAndroidJni::PlayThreadProcess() : _playing, _playWarning
  AudioDeviceAndroidJni::RecThreadProcess() : _recording, _recWarning

Furthermore, playback/record thread may cause some more problem when condition wait timeout. Since these thread functions use CriticalSectionScoped and unlock it manullay before condition wait. When the wait timeout, it do not acquire the mutex again and make CriticalSectionScoped out of scope.

Comment 1

[Jason Smith [:jsmith]]

Haven't started evangelizing these flags to groups yet, but might as well start setting this. I'll email this out to groups to indicate the whiteboard I've indicated here - which means blocking getUserMedia v1 ship for b2g support.