Closed
Bug 1300818
Opened 8 years ago
Closed 8 years ago
Performance is bad for somewhat complex web audio chains (specially if other things are happening on the page at the same time)
Categories
(Core :: Web Audio, defect, P1)
Tracking
()
RESOLVED
FIXED
mozilla52
People
(Reporter: sole, Assigned: padenot)
References
Details
(Keywords: DevAdvocacy, regression)
Attachments
(1 file)
2.47 KB,
patch
|
jesup
:
review+
ritu
:
approval-mozilla-aurora+
ritu
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
You can experience some degree of cutting out in http://sole.github.io/test_cases/web_audio/thx_cutting_out/ with 26 oscillators (I made the test for a previous bug, so the description shown there doesn't totally match this issue). The cutting out is way more acute when rendering WebGL along with playing Web Audio, as you can see here where the THX sound is in context: https://soledadpenades.com/files/t/2015_howa/#1 the above shows terribly cut out and distorted sound... which seems to change depending on the automation so I might suspect some relation here. This used to play quite smoothly a few months ago (at least in December 2015), so this would be a regression. I tested in up to date Stable, Developer Edition and Nightly. All of them are showing the same crackling output. My laptop is "slow", so maybe you'll need a "slow" machine to reproduce this. But again, I could run this nicely in the same laptop in December.
Reporter | ||
Comment 1•8 years ago
|
||
If it helps, I've downloaded 44.02 and tried the full demo with WebGL and the audio doesn't crackle to death there.
Updated•8 years ago
|
Assignee | ||
Comment 2•8 years ago
|
||
Alex, this looks like a fallout from our latency improvements on OSX, mind to have a look ? We lowered the latency and now this crackles, because this demos has high CPU usage. We have a pref ("media.cubeb_latency_ms") to easily change the latency.
Flags: needinfo?(achronop)
Updated•8 years ago
|
Assignee: nobody → achronop
Flags: needinfo?(achronop)
Updated•8 years ago
|
Flags: needinfo?(achronop)
Updated•8 years ago
|
Rank: 23 → 15
Priority: P2 → P1
Comment 3•8 years ago
|
||
I am testing in a Nightly (Build identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:51.0) Gecko/20100101 Firefox/51.0) and a 44.02. I am not able to repro the basted sound even with 30 oscillators. My system is late Mac Book Pro. Thus I try to compare the CPU load (from Activity Monitor) between Nightly and Firefox 44.02. CPU load before test 2.6-2.8% WebAudio Nightly: 5.3 - 5.8% Firefox 44.02: 5.7 - 7.6% WebAudio + WebGL Nightly: 14.8% Firefox 44.02: 20.1% From my side I am not able to see a clear indication for what is the cause. Could you please check the your cpu load between the two versions of FF and tell me what you see?
Flags: needinfo?(achronop) → needinfo?(sole)
Comment 4•8 years ago
|
||
19:31.18 INFO: Last good revision: 74166e0168385eba427642965b93c7ad010662ca 19:31.18 INFO: First bad revision: 3785489fa210d38b890ab73f21202b94c5528c1f 19:31.18 INFO: Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=74166e0168385eba427642965b93c7ad010662ca&tochange=3785489fa210d38b890ab73f21202b94c5528c1f 19:31.51 INFO: Looks like the following bug has the changes which introduced the regression: https://bugzilla.mozilla.org/show_bug.cgi?id=1222405
Comment 5•8 years ago
|
||
There was a performance regression introduced by Bug 1222405, but that was (hopefully!) fixed in Bug 1240054.
Reporter | ||
Comment 6•8 years ago
|
||
OK, here's some numbers! * just web audio * ================== nightly web content: 52% nightly: 5% - firefox 44.02: 38% * webgl+webaudio * ================== nightly web content: 150% nightly: 28% - firefox 44:02: 123% (and when the intro sound finishes and eventually oscillators etc are GCollected) nightly web content: 64% nightly: 23% - firefox 44.02: 70% As you can see, this demo is pushing this hardware to exhaustion O:-)
Flags: needinfo?(sole)
Updated•8 years ago
|
status-firefox49:
--- → affected
status-firefox50:
--- → affected
status-firefox52:
--- → affected
Version: Trunk → 45 Branch
Updated•8 years ago
|
status-firefox-esr45:
--- → wontfix
Keywords: regressionwindow-wanted
Comment 7•8 years ago
|
||
The existing theory is that the error is created due to the new smaller latency used by the audiounit backend (cubeb). It was 512 and now for the given scenario should be 256. Bug 1301648 created to allow the user to change the latency from a pref. When the latter reaches m-c reporter will be asked to repro this bug with different latency values.
Comment 8•8 years ago
|
||
I copy here a video captured by sole that shows the problem: https://www.youtube.com/watch?v=DXknSW9fibA&feature=youtu.be Also please note that Bug 1301648 made it to central and we are expecting to reach nightly in order to ask sole to retest.
Comment 9•8 years ago
|
||
Sole, now that new pref reached nightly you can test the same scenario with bigger values of latency. In order to do that you need to add the following pref in about:config media.cubeb_latency_msg_frames (integer) = 512 Add new pref by right clicking in about:config -> New -> Integer and set the name and the value.
Comment 10•8 years ago
|
||
Sole responded on IRC#media that latency of 512 fixed the performance issue.
Assignee | ||
Comment 12•8 years ago
|
||
We are going to be smarter than than, we haven't had time to write the patch just yet.
Flags: needinfo?(achronop)
Comment 13•8 years ago
|
||
Just to close the loop: We will have a solution for Beta (Fx50). I totally agree with Paul that we don't want to revert back to 512 in Nightly; we want to fix the core issue. We'll see what makes sense for Fx50.
Assignee | ||
Comment 14•8 years ago
|
||
I'm getting people to test this, as I don't have the right computers.
Attachment #8801160 -
Flags: review?(rjesup)
Assignee | ||
Updated•8 years ago
|
Assignee: achronop → padenot
Status: NEW → ASSIGNED
Updated•8 years ago
|
Attachment #8801160 -
Flags: review?(rjesup) → review+
Comment 15•8 years ago
|
||
Pushed by rjesup@wgate.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/4f0af21f7759 Cap latency at 512 frames for some mac models. r=jesup
Comment 16•8 years ago
|
||
Pushed by rjesup@wgate.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/f2d64ec287a1 bustage fix rs=kwierso on a CLOSED TREE
Comment 17•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/4f0af21f7759 https://hg.mozilla.org/mozilla-central/rev/f2d64ec287a1
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla52
Comment 18•8 years ago
|
||
Comment on attachment 8801160 [details] [diff] [review] Cap latency at 512 frames for some mac models Approval Request Comment [Feature/regressing bug #]: Fallout from our latency improvements on OSX. We lowered the latency and now this crackles on lower end Macs. [User impact if declined]: Crackles and audio distortion on lower end Macs. [Describe test coverage new/current, TreeHerder]: Manual testing, verified by the reporter [Risks and why]: Virtually no risk. We don't change the behavior on higher end Macs, and we revert to the longer latency (prior to our latency improvements) for lower end Macs. [String/UUID change made/needed]: None
Attachment #8801160 -
Flags: approval-mozilla-beta?
Attachment #8801160 -
Flags: approval-mozilla-aurora?
Comment on attachment 8801160 [details] [diff] [review] Cap latency at 512 frames for some mac models Let's stabilize this on Aurora51 before uplifting to Beta50. This hasn't had much time to stabilize on Nightly52 either.
Attachment #8801160 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment 20•8 years ago
|
||
bugherder uplift |
https://hg.mozilla.org/releases/mozilla-aurora/rev/3777ed2589ae https://hg.mozilla.org/releases/mozilla-aurora/rev/be9b2b04f7e3
Comment 21•8 years ago
|
||
I'll second that this is quite low risk, and fixes something that affects most Mac Airs and non-pro Macbooks
Comment 22•8 years ago
|
||
We need to get this in to Fx50. I'm not worried about this causing regressions, and it's not the sort of patch that needs much bake time.
Comment on attachment 8801160 [details] [diff] [review] Cap latency at 512 frames for some mac models Let's uplift to Beta50.
Attachment #8801160 -
Flags: approval-mozilla-beta? → approval-mozilla-beta+
Comment 24•8 years ago
|
||
bugherder uplift |
https://hg.mozilla.org/releases/mozilla-beta/rev/a70d8dc4e3f9 https://hg.mozilla.org/releases/mozilla-beta/rev/de034e946e3c
You need to log in
before you can comment on or make changes to this bug.
Description
•