Alternatives for module loading of AudioWorklet

[guest271314]

Describe the feature

An alternative to module loading of AudioWorklet.

Is there a prototype?

The closest that I am aware of is Anonymous inline modules

Describe the feature in more detail

When I run this code https://github.com/guest271314/webtransport/blob/main/webTransportAudioWorkletWebAssemblyMemoryGrow.js at console on GitHub I get this error

Refused to load the script 'blob:https://github.com/66922005-0952-462d-abbe-a0983c78079f' because it violates the following Content Security Policy directive: "script-src github.githubassets.com". Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback.

VM187:238 DOMException: The user aborted a request.
webTransportAudioWorkletMemoryGrow @ VM187:238
async function (async)
webTransportAudioWorkletMemoryGrow @ VM187:113
(anonymous) @ VM194:1

which is the Blob URL at

    const worklet = URL.createObjectURL(
      new Blob(
        [
          registerProcessor(
            'audio-worklet-quic-transport-stream',
            AudioWorkletQuicTransportStream
          ),
        ],
        {
          type: 'text/javascript',
        }
      )
    );

We should be able to run AudioWorklet using inline code

    class AudioWorkletProcessor {}
    class AudioWorkletQuicTransportStream extends AudioWorkletProcessor {
    // ...
    }

to avoid making a fetch request.

[guest271314]

This is not a proposal to get rid of module loading AudioWorklet, only to provide alternative methods of initiating AudioWorklet - the inline code will still be in, or create AudioWorkletGlobalScope - just not using (Ecmascript/JavaScript) modules.

[padenot]

This should be talked about at the EcmaScript and Worklet level before considering using it in Web Audio, this is not really a Web Audio API issue.

Using AudioWorklet without multiple source file and without doing any fetch is possible today however:

<script type="worklet">
registerProcessor('test-param', class param extends AudioWorkletProcessor {
  constructor() {
    super();
    console.log("ctor");
  }
  process(input, output, parameters) {
    return true;
  }
});
</script>
<script>
var ac = new AudioContext;
var source = document.querySelector("script[type=worklet]")
var text = source.innerText;
const blob = new Blob([text], {type: "application/javascript"});

var url = URL.createObjectURL(blob);
ac.audioWorklet.addModule(url).then(() => {
  var node = new AudioWorkletNode(ac, 'test-param');
});
</script>

Here I'm using a separate script tag, with a type of "worklet". If it's not a JavaScript MIME type (or is not omitted, like here), it's treated as a simple data block that is not executed, but using a simple string also works well.

[guest271314]

This should be talked about at the EcmaScript and Worklet level

I do not see how those specifications are controlling as to Web Audio.

Using AudioWorklet without multiple source file and without doing any fetch

A fetch request is made in the code example you posted at

var url = URL.createObjectURL(blob);
ac.audioWorklet.addModule(url)

what I propose is that an option exist to initiate AudioWorklet using inline code, without making any request.

[guest271314]

What happens when a user tries to create an AudioWorklet instance on github.com for example this page using the code at https://github.com/WebAudio/web-audio-api-v2/issues/109#issuecomment-756634198?

[guest271314]

This should be talked about at the EcmaScript and Worklet level before considering using it in Web Audio

@padenot I am banned from both WHATWG/HTML and TC39 so I will not be able to file issues at those entities.

Using AudioWorklet without multiple source file and without doing any fetch is possible today however:

If you run the code you posted at console at this page or any on github.com you will get CSP errors. I used Chromium DevTools Local Overrides to workaround the issue. However, there should be a means to load AudioWorklet without making a fetch request if we have the inline code already.

It is a Web Audio issue because in this case using Ecmascript module restricts the ability of AudioWorklet usage at the outset.