[AUDIO_WORKLET] Optimise the copy back from wasm's heap to JS

[cwoffenden]

Short version: this improves the copy back from the audio worklet's heap to JS by 7-12x depending on the browser.

Since we pass in the stack for the worklet from the caller's heap, its address doesn't change. And since the render quantum size doesn't change after the audio worklet creation, the stack positions for the audio buffers do not change either. This optimisation adds one-time subarray views and replaces the float-by-float copy with a simple set() per channel (per output).

To prove this doesn't break anything, tests of the audio worklet API to compare before and after have already landed in #23394, merged here; they can be run using:

test/runner interactive.test_audio_worklet_stereo_io
test/runner interactive.test_audio_worklet_2x_stereo_io
test/runner interactive.test_audio_worklet_mono_io
test/runner interactive.test_audio_worklet_2x_hard_pan_io 

A benchmark of the extracted copy before and after is here:

https://wip.numfum.com/cw/2024-10-29/index.html

This PR fulfils the garbage-free requirement as well as having the performance boost. Multiple output buffers are created with addresses at the first entries in the AW's stack, and the number of ins and outs can change dynamically (using or not the predefined buffers). There are tests for buffer overflows as well as sanity.

(Edited to take the content from the conversation below and turn this from a proposal to a summary.)

[juj]

Nice idea! It looks like this PR carries the rename from the other PR. Rebase/merge should hide it?

[cwoffenden]

Nice idea!

A shower thought, as all good ideas are!

It looks like this PR carries the rename from the other PR. Rebase/merge should hide it?

Yes, this one was rebased off the earlier one so should have the same commit IDs.

[cwoffenden]

EDIT: every test I tried suggests no, the stack is only used once we hit Wasm in the callback.

@juj or someone who knows more about the internals of this than me: on entering AudioWorkletProcessor.process() nothing else will have used the stack beforehand? I've verified stack top is always the same when we enter the AudioWorkletProcessor's contructor and process() and it's always the same as the the address (plus length) passed to emscripten_start_wasm_audio_worklet_thread_async().

To rephrase: unless the audio worklet explicitly uses the stack functions from JS, nothing external from Wasm will before callbackFunction() is called?

[cwoffenden]

Some notes: lots of experiments with the stack allocations, minimum sizes, various flags (STACK_OVERFLOW_CHECK and ASSERTIONS) and we have some very happy code! View allocations are all in the constructor, with sanity checks performed on the address.

Next is to benchmark it.

[cwoffenden]

Benchmarks of the main part of the audio copy done:

https://wip.numfum.com/cw/2024-10-29/index.html

Testing on my M2 Mac Studio in Chrome and Safari this PR is around 15x faster on the float copy, e.g. the original being 0.625µs per process() and the new code 0.044µs. On my aging iPhone 11 it's 1.182µs before and 0.199µs after.

Firefox on Mac has the largest difference: 5.090µs before and 0.123µs after, a 41x speed-up. Updating Firefox fixes this and it's now 0.916µs before and 0.118µs after.

@juj if we're in agreement that the simplified standalone JavaScript test code is doing the right thing (it's short and a copy and paste), I can gather numbers from regular hardware (we have a wall of Chromebooks at work).

Next I'll need to create tests to show that this still works with various input and output configs.

EDIT: a 7-12x speed-up seems typical on x64 Windows or Linux.

[cwoffenden]

Note to me: look at #22808 ✅

[cwoffenden]

I can split out the tests from the code changes

That would be awesome, thank you.

Tests moved to #23394 (since they don't require these changes).

[cwoffenden]

Since this has had a lot of comments and changes since its first commit in October I've edited the initial comment to contain the findings and results, and merged the tests which landed in main. Besides the comment/error message in library_webaudio.js all of the changes are now in a single file.

[cwoffenden]

Odd, GH closed this when I renamed the branch to merge into a fork (it's residing in cw-audio-optimised-copy).

If there's any interest in this I can re-open another PR.