Perhaps an initial implementation of RegisterProcessor() would send the |name| to the audioWorklet on the main thread to build the start of a node name to parameter descriptor map. The map (hashtable or array) may initially just have the name key (with no parameter descriptors), so that the AudioWorkletNode constructor can throw when the name does not exist. The JS interaction and AudioParamDescriptors can be added separately.

Following our discussion on IRC, I'm not sure yet how to implement this. The code to implement is located here: https://searchfox.org/mozilla-central/source/dom/worklet/AudioWorkletGlobalScope.cpp#36 Looking at the spec: "Queue a task to the control thread to add the key-value pair (name - descriptors) to the node name to parameter descriptor map of the associated BaseAudioContext." However, in AudioWorkletGlobalScope, we don't have any reference to the AudioContext, nor in the AudioWorklet (which is a Worklet C++ object, with a specific mType value). My feeling is that we should probably have Worklet be an abstract class, and AudioWorklet inheriting it, keeping a reference on the audiocontext, so it can transmit it to the AudioWorkletGlobalScope too. Thus, in AudioWorkletGlobalScope::RegisterProcessor, we can easily access BaseAudioContext and update it (using something like https://searchfox.org/mozilla-central/source/dom/worklet/WorkletThread.cpp#397 as you suggested). What do you think? Is their any other way to retrieve the audio context? Note that we already discussed the idea of having Worklet being an abstract class in bug 1470856 comment 3, but there was not enough reason to do it at that time.

Note that having access to the audio context would be also useful to fill AudioWorkletGlobalScope's attributes: https://webaudio.github.io/web-audio-api/#AudioWorkletGlobalScope-attributes

(In reply to Arnaud Bienner from comment #2) > Note that having access to the audio context would be also useful to fill > AudioWorkletGlobalScope's attributes: > https://webaudio.github.io/web-audio-api/#AudioWorkletGlobalScope-attributes AudioWorkletGlobalScope and AudioContext are single-thread objects living on different threads, and so it's not as simple as making the AudioContext available to the AudioWorkletGlobalScope. I expect we'll need to pass the result of AudioDestinationNode::Stream() to AudioWorkletGlobalScope somehow. That has what we need for currentFrame etc. (In reply to Arnaud Bienner from comment #1) > However, in AudioWorkletGlobalScope, we don't have any reference to the > AudioContext, nor in the AudioWorklet (which is a Worklet C++ object, with a > specific mType value). You are right that Worklet code doesn't have the infrastructure to do what is needed. We can't easily reference the AudioContext directly from the worklet thread because the AudioContext reference count can only be modified on the main thread. (Cycle-collected objects are always single thread objects.) AudioDestinationNode::Stream() could be useful here too because the stream can be used on both threads and stream->Engine()->NodeMainThread() can be used on the main thread to get back to the AudioDestinationNode, which knows the AudioContext. We also don't have a good way to pass a handle to the worklet from worklet thread to main thread. The closest thing we have right now is WorkletLoadInfo::Principal(). The WorkletLoadInfo exists on both threads, but Principal() is used only on the main thread. Currently the way to pass a worklet handle from main thread to worklet thread is via WorkletThread. There can be more than one worklet using the same worklet thread and so I'm planning to create a new thread-safe ref-counted object that doesn't keep the Worklet alive but is owned by Worklet and WorkletGlobalScope. I'm thinking of the name "WorkletPrivate" because this would kind of correspond to WorkerPrivate. I'm not sure whether we need to, but this object could be used to pass a handle to the worklet from worklet to main thread (as well as the other way). > My feeling is that we should probably have Worklet be an abstract class, and > AudioWorklet inheriting it, keeping a reference on the audiocontext, so it > can transmit it to the AudioWorkletGlobalScope too. > Thus, in AudioWorkletGlobalScope::RegisterProcessor, we can easily access > BaseAudioContext and update it (using something like > https://searchfox.org/mozilla-central/source/dom/worklet/WorkletThread. > cpp#397 as you suggested). > > What do you think? > Is their any other way to retrieve the audio context? Subclassing Worklet would provide some of what is needed, but the fact that AudioWorklet adds no members to Worklet seems to be a hint that there is not much that will be specific to AudioWorklet, and so I'm still not expecting that subclassing Worklet will be desirable long term. Subclassing Worklet does not solve the problem of passing a worklet handle from worklet thread to main thread. My current thinking is that it will be more useful to subclass WorkletPrivate because there will be more AudioWorklet-specific things there and Worklet can delegate to WorkletPrivate when required. I haven't created WorkletPrivate yet, though. If you'd like to proceed with something in the meantime, then using AudioDestinationNode::Stream() is my best suggestion for accessing the AudioContext. I expect we'll need a stream in AudioWorkletGlobalScope anyway (for currentFrame etc). Passing the stream through may involve creating a separate Worklet constructor for AudioWorklet. Storing an owning reference to the stream on the Worklet class (even though PaintWorklet would not use it) would be the simple option for now AFAIK. Although not particularly elegant, I think we can live with one extra member until we have WorkletPrivate, and then move it to AudioWorkletPrivate at that point.

Pushed to try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=7be59a53f14f6aeb9c54350abfd5dc1acf780ca2

Try is green. Karl: do you need to review my last changes or can I request checkin? Note that baku accepted the revision.

The convention for "accepted this revision" is that the reviewer need not see the patch again, unless something new is introduced, or if you'd like to ask the reviewer about something. IIRC there is UI to re-request review in this case (even if that might require removing and re-adding the reviewer, but I think I did find a better way). baku's review is sufficient too.

Pushed by csabou@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/7355fb2908e5 implement AudioWorkletGlobalScope::RegisterProcessor(). r=baku,karlt