1240261 - Firefox's WebAudio context decodeAudioData() is very slow compared to Chrome's implementation

Status: NEW

(Core :: Web Audio, defect, P3)

Description

[Naomi Aro]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:43.0) Gecko/20100101 Firefox/43.0
Build ID: 20160105164030

Steps to reproduce:

I'm running a time profile on the decoding step.

console.time('decode ' + this.src);

this.ac.decodeAudioData(
    audioData,
    (audioBuffer) => {
        console.timeEnd('decode ' + this.src);
        this.audioBuffer = audioBuffer;
    },
    (err) => { 
         ...
    }
);


Actual results:

for the same file, some results are

Chrome: 237.986ms / Firefox: 1387.21ms
Chrome: 737.142ms / Firefox: 1391.77ms
Chrome: 778.843ms / Firefox: 2184.31ms


Expected results:

Hopefully since Chrome is able to decode the audio consistently faster, improvements can be made to match this decoding execution speed in Firefox.

Comment 1

[Chris Peterson [:cpeterson]]

Thanks for reporting this problem, Naomi!

Comment 2

[Maire Reavy [:mreavy]]

Paul -- Is this worth adding to our benchmarks?  Is P2 a reasonable priority or should this be higher?

Comment 3

[Paul Adenot (:padenot)]

We need to check if this is for all files, or just some of them. Keeping NI.

Comment 4

[Paul Adenot (:padenot)]

Chinmay has added time taken to https://chinpen.net/decodethis/, we are consistently slower, and decode a lot less audio files.

Comment 5

[Bulk Bug Changes for mreavy's org]

Mass change P2->P3 to align with new Mozilla triage process.

Comment 6

[Paul Adenot (:padenot)]

We now are playing more of the files, we're only failing on f32 float compared to chrome (96 vs 97 played files):

Updated benchmark results:

• Firefox Nightly OSX, rdd disabled: 3671ms
• Firefox Nightly OSX, rdd enabled: 8379ms
• Chrome stable, OSX: 1193ms

This has been measured by summing the last column of https://chinpen.net/decodethis/:

sum = 0; 
$$('td:last-child').forEach((e) => {
 if (e.previousElementSibling.textContent == "Passed") {
   sum += parseFloat(e.textContent);
 }});
console.log(sum + "ms");

Still some work to do.

Comment 7

[Paul Adenot (:padenot)]

We're now down to 2047ms on the same machine, with the RDD enabled. Michael, that's expected with your recent changes right? Is there more coming?

Comment 8

[Michael Froman [:mjf]]

With batch decoding landed in Bug 1568058 I would expect an improvement on webaudio that can be decoded on RDD. That is currently Vorbis, Opus, and WAV on macOS and Linux. Currently Windows isn't decoding audio on RDD, but pref-ing on Vorbis on RDD should be landing soon (hopefully today).

If you'd like to compare RDD w/ batch vs RDD w/o batch decoding, setting media.rdd-webaudio.batch.size to '1' will turn off batch decoding.
Using Nightly on my (ancient) MacPro, I get 15594ms vs 4609ms (batch off vs on).
Using a local build on my linux box, I get 14402ms vs 5649ms (batch off vs on).
For some additional test data, see https://bugzilla.mozilla.org/show_bug.cgi?id=1568058#c20.

I have plans to catch up Windows RDD audio decoding with macOS and Linux as long as we don't run into additional sandbox complications there. We should be moving additional audio formats to RDD decoding as well, with mp3 likely being the next candidate.