Have a single AudioWorkletGlobalScope per BaseAudioContext

[padenot]

I think this was forgotten when writing a PR for #1511 (no wonder, it was so big).

The resolution seem to be #1511 (comment). It's also a resolution in #966 (comment).

It's rather critical for interop and is what Chrome implements (and we'll implement). Authors need to reliably be able to share data between instances (wave tables, audio buffers, other precomputed data, etc.).

[hoch]

Yes, this is an oversight and the fix should be trivial. So you think the following text in the spec is problematic? (From here)

At least one AudioWorkletGlobalScope exists for each AudioContext that contains one or more AudioWorkletNodes.

[padenot]

Yes, it means you can't really count on the fact that you can read the expandos you set in one process in another process.

[hoch]

Also Worklet's addModule method and the construction process of WorkletGlobalScope do not seem to be compatible with the notion of parallelism. In fact, there is a bit of history on this sentence - @joeberkovitz wanted to have some room for the future so we can support multi-threading support by having multiple AudioWorkletGlobalScopes.

Here's the relevant discussion: https://github.com/WebAudio/web-audio-api/pull/1020/files#r88695255

But I think it might need a completely different approach to support the multi-threading without violating many assumptions that are already in place. Hence, SGTM.