[audioworklet] AudioWorkletGlobalScope : expand the specification to allow adding common classes to the AudioWorkletProcessor's global scope

[flatmax]

In some instances, it is necessary to add URL fetched code to the AudioWorkletProcessor's global scope which are outside the AudioWorkletProcessor's class's js file.

One example is when many AudioWorkletProcessor js files require classes which are common to all, and thus these common classes are in an external js file to the AudioWorkletProcessor's file.

I am not aware of any method to fetch URLs from inside a module's js file during the execution of the AudioWorkletGlobalScope::addModule call.

Do you agree that the web-audio-api specification requires expansion to allow code injection into the AudioWorkletGlobalScope so that AudioWorkletProcessor extended classes may have access to such common code in their scope ?

In this situation, we need to be able to do the following :
this.context.audioWorklet.addModule('CommonSignalProcessingClasses.js');
this.context.audioWorklet.addModule('FilterAudioWorkletProcessor.js');

Where the common classes in the file CommonSignalProcessingClasses.js are added to the AudioWorkletGlobalScope in such a way that the AudioWorkletProcessor's scope (specified in the FilterAudioWorkletProcessor.js file) allows access/use of the these common classes.

[flatmax]

An even better method to be able to do this may be to allow actual code injection, for example a new method in the AudioWorkletGlobalScope :
AudioWorkletGlobalScope::addFunction
or
AudioWorkletGlobalScope::addClass

Where we can have a common function or class resident in the MainGlobalScope and place that function/class in the AudioWorkletGlobalScope so that the AudioWorkletProcesor can access and execute it as required. The AudioWorkletGlobalScope doesn't require access to the MainGlobalScope to execute the common code because it is resident in the AudioWorkletGlobalScope.

In this second approach the original URL is only fetched once, but the code is injectable into as many AudioWorkletGlobalScope objects as we require.

[hoch]

We already discussed this issue - why fetch() does not exist in AWGS?
#1439

common function or class resident in the main thread and execute that in some way to place that in the AudioWorkletGlobalScope

MessagePort can send WASM module. Or you should be able to eval() after passing stringified function def from the main thread, but...

[padenot]

... but ?

[hoch]

I think this issue can be closed. Was waiting for one of editors to take a look and close.

[flatmax]

I am planning to get back to this task - this week or next week.

[hoch]

@flatmax What are you trying to accomplish here? I clarified this issue has been already discussed. Do you want to discuss something different than using fetch() or module loading in AWGS?

[flatmax]

Feel free to close it - thanks for the pointers.

[flatmax]

Just a note on this closed issue.

This repo (https://github.com/madChopsCoderAu/WASMAudio) instantiates the WASM code in the AudioWorkletGlobalScope. This removes the problem of trying to get WASM code from the Main Global Scope into the AudioWorkletGlobalScope.

It gets the idea for embedding the WASM code in the AudioWorkletGlobalScope from this emscripten issue : emscripten-core/emscripten#6230

[hoch]

Ideally, you should be able to transfer WASM module as a optional argument of AudioWorkletNode constructor. That'll guarantee you can create an instance out of the module in synchronously. (i.e. before the node can produces the audio stream)

Using inlined (or embedded) WASM data potentially can block the render thread when the compilation kicks in. So doing it on the main thread side would be the better practice.