How exactly does the wasm audio worklet API works?

[msqr1]

On the docs, it says that the audio worklet runs in a wasm worker, what does it mean? Doesn't creating the audio worklet create another thread already?
It also says that the user will not immplement the ScriptProcessorNode by themselves, but isn't the audio worklet uses the audioworklet and not the deprecated ScriptProcessorNode

[sbc100]

@juj

[msqr1]

@juj you implemented this, right?

[sbc100]

I assume you read the documentation on this: https://emscripten.org/docs/api_reference/wasm_audio_worklets.html ?

[msqr1]

Yeah

[sbc100]

In terms of the relationship between wasm workers and audio worklet, IIUC and audio worklet in emscripten is implemented as a wasm worker. The wasm worker runs on the audio worklet thread, so there is exactly one worker created when you create an audio worklet.

I think the docs mention ScriptProcessorNode only to say that you don't need to worry about implementing any of the stuff at that level when using this API. emscripten takes care of the internals. And yes, we don't use ScriptProcessorNode internally.

[msqr1]

Why does the wasm worker run on top of the audio worklet? Didn't we instantiate the wasm module in audioworkletglobalscope, where is the part that a wasm worker is required?

One more thing, could we allow the user to specify block size other than the default 128? I think this can be easily implemented.

[sbc100]

A Wasm Worker is just nothing really more than some code to host/run run the wasm module. Its the minimal thing that is required for the compiled code to be able to communicate with other workers via shared memory.

Perhaps open a new issue to discuss the block size (I have vague memories of it being discussed elsewhere).

[msqr1]

Ok