Add -sAUDIO_WORKLET=2 build mode #20630
Conversation
…ed WebAssembly Modules and Emscripten runtime .js that is compatible with being manually loaded inside an AudioWorkletGlobalScope.
|
Thanks for working on this, @juj! 🙏 |
| settings.EXPORTED_RUNTIME_METHODS += ['stackSave', 'stackAlloc', 'stackRestore'] | ||
| elif settings.AUDIO_WORKLET == 2: | ||
| settings.BINARYEN_ASYNC_COMPILATION = 0 # Run synchronous Wasm initialization inside AudioWorklet. | ||
| settings.SINGLE_FILE = 1 # All code must be embedded in a single .js file when targeting -sAUDIO_WORKLET=2 |
There was a problem hiding this comment.
I don't think this needs to be a requirement. I think a better pattern is to fetch the wasm binary on the main thread and then transfer it to the AudioWorklet processor.
|
Whatever happened to this PR? It would be great to have this merged, it's a wonderful feature. |
I still think this would be a great thing to land |
|
I'm somewhat reluctant to add yet another build mode that we have to test and maintain over time. This one is especially tricky because we it cannot be tested except in interactive browser tests (since we don't have any way to play audio in our test framework without user interaction today). |
Fair enough, but the current methodology forces us to use |
I won't push back too hard given there are genuine use cases. But I would like to make sure we have as good as possible test coverage. Also, I think perhaps |
|
|
|
I have no strong opinion on how to configure this, but I think it's actually an important use-case and I know it's already being used in a few cases using the -sENVIRONMENT=SHELL, https://developer.chrome.com/blog/audio-worklet-design-pattern/#setting-up being one of them, meaning it's most likely somewhat widespread. My concern is that without explicit support, the SHELL solution may break over time. |
This PR contains a new
-sAUDIO_WORKLET=2build mode, which enables building Emscripten output that is compatible with being manually loaded inside an AudioWorkletGlobalScope.This seeks to resolve #20581. However this PR is not yet 100% complete for landing, but posting here to showcase what this code would look like to solicit reviews.
I copied and adapted the test code from https://github.com/GoogleChromeLabs/web-audio-samples/tree/main/src/audio-worklet/design-pattern/wasm. It is a good starting point, although I am not that happy about the contents of wasm-worklet-processor.js, that code does not show what I think would be good practices for people to follow when integrating JS and Wasm, but at least it gives a solid surface area to run in tests.
This is a bit of a draft, as the code hacks passing --export-es6 to acorn. Also noticed that Closure compiler and MINIMAL_RUNTIME don't quite work due to that --export-es6 syntax.
I am not sure if I want to champion developing this, I mainly wanted to post this as an example to help people see how adding a test case for this would work.