Closed
Bug 937119
Opened 11 years ago
Closed 11 years ago
Audio broken on Motorola RAZR i
Categories
(Core :: WebRTC: Audio/Video, defect)
Tracking
()
RESOLVED
FIXED
mozilla28
Tracking | Status | |
---|---|---|
firefox27 | --- | unaffected |
firefox28 | --- | fixed |
People
(Reporter: gcp, Assigned: gcp)
Details
Attachments
(4 files)
1016.04 KB,
text/plain
|
Details | |
1016.04 KB,
text/plain
|
Details | |
2.15 KB,
patch
|
jesup
:
review+
|
Details | Diff | Splinter Review |
1.05 KB,
patch
|
jesup
:
review+
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 1•11 years ago
|
||
Assignee | ||
Comment 2•11 years ago
|
||
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.
Assignee | ||
Comment 3•11 years ago
|
||
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)
Assignee | ||
Comment 4•11 years ago
|
||
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 :-/
Assignee | ||
Comment 5•11 years ago
|
||
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)
Updated•11 years ago
|
Attachment #830894 -
Flags: review?(rjesup) → review+
Updated•11 years ago
|
Attachment #830900 -
Flags: review?(rjesup) → review+
Comment 7•11 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/0434656a5176
https://hg.mozilla.org/integration/mozilla-inbound/rev/f7b74d242905
status-firefox27:
--- → unaffected
status-firefox28:
--- → affected
Target Milestone: --- → mozilla28
Comment 8•11 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/0434656a5176
https://hg.mozilla.org/mozilla-central/rev/f7b74d242905
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Updated•11 years ago
|
Updated•6 years ago
|
No longer blocks: webrtc_upstream_bugs
You need to log in
before you can comment on or make changes to this bug.
Description
•