Closed Bug 937119 Opened 11 years ago Closed 11 years ago

Audio broken on Motorola RAZR i

Categories

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

x86
Android
defect
Not set
major

Tracking

()

RESOLVED FIXED
mozilla28
Tracking Status
firefox27 --- unaffected
firefox28 --- fixed

People

(Reporter: gcp, Assigned: gcp)

Details

Attachments

(4 files)

After the update to webrtc.org 3.43, gum Audio on the Motorola RAZR i no longer works (audio just ticks, doesn't seem to play back). We initially suspected an x86 issue, but it works fine on the Tab 3.
Based on the attached logs, I start looking where the stereo errors were coming from, suspecting that perhaps the RAZRi had some issues with mono vs stereo recording. However, the errors are caused by something else entirely, in fact closer inspection would have revealed them to happen on the ARM too. They're caused by an upstream bug in the OpenSLES driver. Patch follows.
The webrtc.org OpenSLES driver claims to not support stereo recording. The calling code will try the detection, get a no, and call SetStereo(false); However, SetStereo is written so it always fails, even if stereo is not enabled. This causes spuriours errors. Fix it so we only fail if someone actually tries to enable stereo. This is an upstream bug, though I don't know if they already fixed it in trunk.
Assignee: nobody → gpascutto
Attachment #830894 - Flags: review?(rjesup)
After "fixing" the stereo errors, I couldn't find much bad in the logs, except for the buffer overruns, which shouldn't have been fatal. The adb logcat from the RAZR had some suspicious messages which seemed to indicate it was running some extra audio conversions and was in general quite spammy, but twiddling with the used sampling rate didn't fix anything. I gave the buffer overruns another shot, and lo and behold, that fixes it. Now I remember that in the last OpenSLES update we also had to increase Google's default buffer sizes. I think we test with crappier devices than they do :-/
The RAZRi isn't fast or low-latency enough to work with 30ms buffers. From a very cursory look at the code this doesn't necessarily increase the latency for other devices, the extra 1x10ms buffer just won't get used.
Attachment #830900 - Flags: review?(rjesup)
Attachment #830894 - Flags: review?(rjesup) → review+
Attachment #830900 - Flags: review?(rjesup) → review+
We should tag this for upstreaming
No longer blocks: webrtc_upstream_bugs
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: