Is Audio Worklets known to be working when compiling with --closure=1?

[mackron]

Thought I'd just ask this as a discussion item rather than a bug report because I'm not sure it actually is a bug or I'm just doing something wrong. I had a report from a user of my audio library about audio not working when compiling with --closure=1. Upon addressing this, I've noticed that emscripten_create_wasm_audio_worklet_processor_async never actually fires the specified callback. It works perfectly fine when not using --closure=1. This is the code I'm using:

MA_ZERO_OBJECT(&workletProcessorOptions);
workletProcessorOptions.name = "miniaudio";

emscripten_create_wasm_audio_worklet_processor_async(audioContext, &workletProcessorOptions, ma_audio_worklet_processor_created__webaudio, pParameters);

So my question is - is the new Audio Worklets functionality known to be working with --closure=1, and if so, is there anything blatantly wrong with my code above (I realise there's not much to go on, but can post more details here if necessary).

[sbc100]

A lot of audio worklet tests in test/test_browser.py do seem to have variants that run with --closure=1. See

emscripten/test/test_browser.py

Line 5735 in 9d830e2

'closure': (['--closure', '1', '-Oz'],),

for example.

So at the least the basic features see me to be tests with closure.

Perhaps take a look at the tests and see if emscripten_create_wasm_audio_worklet_processor_async is covered by a closure test?

BTW, closure doesn't effect the native code, only the JS code, it its unlikely to be your C++ code that is at fault. How are your users consuming your library? E.g. As source code or as pre-built ar archive/library?

[mackron]

Thanks. I'll have a poke around those examples.

Users add the source file directly to their source tree, so they're in control over the specific compilation and linking flags.