Remove compileStreaming and instantiateStreaming from AudioWorkletGlobalScope.WebAssembly implementation

[guest271314]

Describe the issue

console.log('compileStreaming' in globalThis.WebAssembly);
console.log('instantiateStreaming' in globalThis.WebAssembly);

both return true at Nightly 78 and Chromium 81.

However, those methods cannot be used in AudioWorkletGlobalScope without throwing a TypeError because Response is not defined in AudioWorkletGlobalScope

https://webassembly.org/docs/web/#process-a-potential-webassembly-response

Process a potential WebAssembly response The above two functions both reuse much of the same infrastructure for extracting bytes from an appropriate Response object, differing only in what they do with those bytes in the end. As such we define the following shared spec-level procedure:

...

Given these values, to process a potential WebAssembly response:

1. Let returnValue be a new promise.
2. Let sourceAsPromise be a promise resolved with argument.
3. Upon fulfillment of sourceAsPromise with value unwrappedSource: i. If unwrappedSource is not a Response object, reject returnValue with a TypeError exception and abort these substeps.

Specification authors object to defining fetch(), thus Response, in AudioWorkletGlobalScope where the methods now are only capable of throwing a TypeError per the WebAsssembly specification, thus should be removed from AudioWorkletGlobalScope.WebAssembly implementation.

Where Is It

1.32.1. Concepts

The AudioWorklet object allows developers to supply scripts (such as JavaScript or WebAssembly code) to process audio on the rendering thread, supporting custom AudioNodes. This processing mechanism ensures synchronous execution of the script code with other built-in AudioNodes in the audio graph.

https://webassembly.org/docs/web/#additional-web-embedding-api

Additional Web Embedding API

In Web embeddings, the following methods are added.

Note that it is expected that compileStreaming and instantiateStreaming be either both present or both absent.

Additional Information

Where specification authors appear to be in firm agreement to not define fetch(), and thus Response, in AudioWorkletGlobalScope https://github.com/WebAudio/web-audio-api-v2/issues/73, where if that decision remains unchanged compileStreaming() and instantiateStreaming() will always only throw a TypeError rendering the methods useless in AudioWorkletGlobalScope.

The WebAssembly specification provides the solution to the bug "both absent" must apply in this case.

If the specification authors conclude that a TypeError being thrown for WebAssembly.compileStreaming() and WebAssembly.instantiateStreaming() which is the only possible outcome due to Response not being defined in AudioWorkletGlobalScope at a minimum a note should be included in the specification to notify users that while compileStreaming() and instantiateStreaming() are defined methods within AudioWorkletGlobalScope using either will only result in a TypeError being thrown as Response is not defined in the AudioWorkletGlobalScope.

[padenot]

Virtual F2F:

• https://webassembly.org/docs/web/ hints at the fact that it might be possible to not expose those in some context, but only makes the Web/Not Web distinction

[guest271314]

@padenot Or, expose Response and fetch in Worklet/AudioWorkletGlocalScope. Hundreds of thousands to millions of MessagePort events and message events is more than likely more expensive than just fetching the input data in AudioWorkletGlobalScope. The design pattern appears to have neglected to consider how to get substantial amounts (potentially an infinite stream) of input data data to AudioWorkletProcessor.

If Response and fetch cannot be defined in AudioWorkletGlobalScope every effort should be made to concretely implement transferable streams to replace the expensive MessagePort implementation. Though we should be able to compare fetch and Response in AudioWorkletGlobalScope to using WebAssembly, Atomics and SharedArrayBuffer to base conclusions about performance on evidence rather than assumptions.

[padenot]

TPAC 2020:

• @hoch will ask around and find out whether it's possible to not expose those in a particular context.

[guest271314]

Another option is to expose Response in AudioWorkletGlobalScope. Then blob() and formData() would need the same non-exposure becaude Blob is not defined in that context either. After thousands of experimental runs I do not have any evidence to support the propostion that Response or fetch() in AudioWorklet will break the API.

[hoch]

The streaming version already excludes the WGS: https://webassembly.github.io/spec/web-api/index.html#streaming-modules

[hoch]

Nothing actionable here in terms of the spec change - the spec seems sufficient, but the implementations do not reflect it correctly. I filed an issue against Chromium: https://crbug.com/1144249

[padenot]

Gecko bug to remove those: https://bugzilla.mozilla.org/show_bug.cgi?id=1711945. I'm closing this, since both implementations are wrong.