Skip to content

[AUDIO_WORKLET] Wait for Wasm instance to start using audio worklet. #24734

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

Conversation

brendandahl
Copy link
Collaborator

This fixes intermittent test failures where the AudioWorklet was used
before the Wasm module was loaded.

Copy link
Member

@dschuff dschuff left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe still want an opinion from @sbc100 but LGTM

Copy link
Collaborator

@sbc100 sbc100 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you happen know if this bug always existed? Was it introduced perhaps in #24190?

readyPromiseResolve = resolve;
readyPromiseReject = reject;
});
moduleRtn = readyPromise = createReadyPromise();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we just do moduleRtn = readyPromise here and unconditionally call createReadyPromise in runtime_common.js ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think if I do that, I'll have to undo the work you did in https://github.com/emscripten-core/emscripten/pull/24418/files and add back a try/catch.

@@ -139,7 +139,7 @@ function run() {

#if PTHREADS || WASM_WORKERS
if ({{{ ENVIRONMENT_IS_WORKER_THREAD() }}}) {
#if MODULARIZE
#if USE_READY_PROMISE
readyPromiseResolve?.(Module);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you can perhaps remove the question marks here too. i.e. we can make USE_READY_PROMISE imply that readyPromiseResolve exists?

This fixes intermittent test failures where the AudioWorklet was used
before the Wasm module was loaded.
This is an automatic change generated by tools/maint/rebaseline_tests.py.

The following (4) test expectation files were updated by
running the tests with `--rebaseline`:

```
test/code_size/audio_worklet_wasm.js updated
code_size/audio_worklet_wasm.json: 5660 => 5719 [+59 bytes / +1.04%]
test/other/codesize/test_codesize_minimal_esm.gzsize updated
test/other/codesize/test_codesize_minimal_esm.jssize updated

Average change: +1.04% (+1.04% - +1.04%)
```
@brendandahl brendandahl force-pushed the audio-worklet-ready branch from f61ac64 to c3647ef Compare July 22, 2025 21:23
@sbc100
Copy link
Collaborator

sbc100 commented Jul 22, 2025

I'm a little wary about extending the use of the module promise outside of the existing usage in -sMODULARIZE. I wonder if there is some other existing signal we could to use here? Perhaps the dependenciesFulfilled callback? I'm not sure if like that any better though :-/

@brendandahl
Copy link
Collaborator Author

That won't work with minimal_runtime. I suppose I could use one of the other hooks like ATINITS or ATPOSTCTORS that works in regular and minimal runtime.

@brendandahl
Copy link
Collaborator Author

Those hooks don't work for wasm workers, but I think i've found another way. With non minimal runtime and wasm workers a message handler is installed that queues all the messages. The cleanup code for this was being installed, but not the setup code.

@brendandahl
Copy link
Collaborator Author

Closing in favor of #24778

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants