[Dolphin] Buffer overrun during audio capturing when under high load

RESOLVED DUPLICATE of bug 1012936

Status

Firefox OS
General
RESOLVED DUPLICATE of bug 1012936
4 years ago
3 years ago

People

(Reporter: pehrsons, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sprd323076])

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
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)
(Reporter)

Updated

4 years ago
Blocks: 981983
(Reporter)

Comment 1

4 years ago
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.
(Reporter)

Comment 2

4 years ago
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!
Flags: needinfo?(sam.hua)
(Reporter)

Comment 4

4 years ago
Sounds like it could be related to bug 1012936.

Updated

4 years ago
Flags: needinfo?(sam.hua)
Whiteboard: [sprd323076]
(Reporter)

Updated

3 years ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1012936
You need to log in before you can comment on or make changes to this bug.