Closed Bug 1300818 Opened 5 years ago Closed 5 years ago
Performance is bad for somewhat complex web audio chains (specially if other things are happening on the page at the same time)
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.
If it helps, I've downloaded 44.02 and tried the full demo with WebGL and the audio doesn't crackle to death there.
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.
Assignee: nobody → achronop
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)
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
There was a performance regression introduced by Bug 1222405, but that was (hopefully!) fixed in Bug 1240054.
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:-)
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.
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.
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.
Sole responded on IRC#media that latency of 512 fixed the performance issue.
Are we going to go back to 512?
We are going to be smarter than than, we haven't had time to write the patch just yet.
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.
I'm getting people to test this, as I don't have the right computers.
Attachment #8801160 - Flags: review?(rjesup)
Assignee: achronop → padenot
Status: NEW → ASSIGNED
Attachment #8801160 - Flags: review?(rjesup) → review+
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/4f0af21f7759 Cap latency at 512 frames for some mac models. r=jesup
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/f2d64ec287a1 bustage fix rs=kwierso on a CLOSED TREE
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
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+
I'll second that this is quite low risk, and fixes something that affects most Mac Airs and non-pro Macbooks
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+
You need to log in before you can comment on or make changes to this bug.