Device: Dolphin gecko-dev branch: master gecko-dev revision: a39cee4de38d9c807e723888adb92b2016132277 (Fri May 30 09:36:53 2014 +0200) Steps to reproduce: 1. Open http://mozilla.github.io/webrtc-landing/gum_test.html in browser. 2. Click on Audio and share the microphone. 3. Observe that audio recording is working fine. 4. Run `adb logcat` in your terminal; cpu usage on the device should now reach 100%. Expected result: Captured audio messed up due to the high cpu load starving the capturing thread. This is what happens on a Keon. Actual result: Captured audio messed up like expected but also contains a lot of "clicking sounds". The reason for the clicking sounds is that the input device is constantly being restarted, as can be seen in logcat. (attachment and deeper analysis to come)
Created attachment 8435498 [details] bug1021484_dolphin_overrun.log The reason for the clicking is input buffer overrun in gonk. I put an 'ALOGE("##### OVERRUN DETECTED #####");' at B2G/frameworks/av/media/libmedia/AudioRecord.cpp:736 and captured the logs from an audio capturing session according to the STR after that. The input device gets restarted in media/webrtc/trunk/webrtc/modules/audio_device/android/opensl_input.cc:435 (OpenSlesInput::HandleOverrun). The cause of the overrun remains unknown so far.
I should also note the following useful comment on OpenSlesInput::HandleOverrun: // When overrun happens there will be more frames received from OpenSL than // the desired number of buffers. It is possible to expand the number of // buffers as you go but that would greatly increase the complexity of this // code. HandleOverrun gracefully handles the scenario by restarting playout, // throwing away all pending audio data. This will sound like a click. This // is also logged to identify these types of clicks. // This function returns true if there has been overrun. Further processing // of audio data should be avoided until this function returns false again. // The function needs to be protected by |crit_sect_|. bool HandleOverrun(int event_id, int event_msg);
Sam, can you find some one from audio team looking into this? Thanks!
Sounds like it could be related to bug 1012936.