Safari doesn't support any open codecs so we're using an asm.js compile of ffmpeg to decode Opus audio here: https://www.scirra.com/labs/audiotest/ The page is very slow to load on an iPad Air 2, despite not processing much data. It only decodes 23 files totalling ~750kb of compressed data. However this considerably slows down loading times for web content that uses this approach.
Could you please clarify how to reproduce the issue? When I load this page on an iPhone 7, WebContent process unexpectedly terminates. On a Mac, I see an "audio test" image after a progress indicator. How can I measure performance, and how can I confirm that this is a WebKit deficiency? Are other browser engined doing better in some way?
Ah, we've actually seen the page terminating as another case, but I couldn't immediately reproduce that. Could that be investigated as the issue instead? I'm sure asm.js is causing some kind of memory leak/crash, and that may be related to the poor performance.
JavaScriptCore doesn't have custom code for asm.js, it's just normal JavaScript for us. So this could be a general JavaScriptCore issue, or a bug in your code. Could you please answer the questions that I asked in the previous comment?
Surely a bug in JavaScript code should not be able to terminate the process? That is definitely a Safari bug if that happens right? We desperately need a way to play a single set of audio files across browsers, so our goal is simply to have a feasible way to decode Opus files in Safari. I made a tweaked version of the test that always uses the asm.js decoder in other browsers even if they natively support Opus: https://www.scirra.com/labs/audiotest/ Safari on a Macbook performed reasonably compared to Chrome on the same test, so actually I am not really concerned about macOS. I am most concerned about iOS. On the iPad Air 2 I timed its loading performance with a stopwatch and it took around 30 seconds to load the page. I hope you would agree this is an exceptional amount of time for decoding ~750kb of audio data. Since Apple bans other browser engines on iOS I don't know how to make a fair comparison; is there anything you would recommend? All I have to go with is the absolute time, which does seem high. Crashing the browser process is also a major problem, since it means we don't have a way to decode the audio at all, even slowly. Apologies for taking a few comments to clarify the issue: never mind about macOS, I am only concerned with iOS here.
Sorry, the link for the test that always uses the asm.js decoder is actually https://www.scirra.com/labs/audiotest2
> Surely a bug in JavaScript code should not be able to terminate the process? That is definitely a Safari bug if that happens right? This is not necessarily the case, a webpage that attempts to use too much RAM will be terminated before it makes the phone unusable. > I hope you would agree this is an exceptional amount of time for decoding ~750kb of audio data. There is no way for me to tell if it's a browser engine deficiency from this alone. What is the best time you get from any mobile browser on any platform, using this same asm.js program? Any desktop browser? Please provide hardware characteristics for a fair comparison. An iPad Air 2 was released in 2014, so it's not the fastest hardware in existence any more.
Agh, turns out you're right - I tried with a Nexus 9 and it was still super slow. I guess it's my fault for just assuming asm.js would be fast! We must have done something wrong with the build for it. Sorry for the misleading report.
Thank you for following up!