I would appreciate if you submit a PR for the group! :)

I gave a second look on this. Here's what we're really missing:

https://webaudio.github.io/web-audio-api/#dom-audioworkletnode-audioworkletnode

• In step 13, the algorithm invokes the AWP constructor with processor construction data which has nodeName, node, serializedOptions, serializedProcessorPort.

https://webaudio.github.io/web-audio-api/#dom-audioworkletprocessor-audioworkletprocessor

• The algorithm doesn't have a way to access serializedOptions from the algorithm above.

Thus, this can be fixed by saying - invoke the constructor of AWP with the argument of processorOptions which is serializedOptions passed from the AWN constructor.

Sorry that I came up with this idea after your created a PR. I hope we can discuss this in the teleconference.

I noticed the inconsistency in the examples when I double-checked the spec for answering this question on Stack Overflow.

I thought it is actually a feature that it is possible to access the options in the custom processor but without having the ability to alter them. It ensures that the AudioWorkletNode and the AudioWorkletProcessor have the same configuration.

As far as I know all current implementations work somehow like this:

class CustomProcessor extends AudioWorkletProcessor {
    constructor(options) {
        // the options can be accessed here...

        // but the call to super doesn't accept any argument (or ignores it)
        // and uses an unmodified copy of the options
        super();
    }
}

@chrisguttandin Your PR looks great and has nothing to do with the problem that I described in #2491 (comment). I'll merge it after adding some markups around the change.

Spec-wise, we need to explain how the processorOptions from the AudioWorkletNode side gets passed to the subclass constructor of AudioWorkletProcessor. The super() of AWP doesn't accept any argument, but the subclass can take advantage of that. Fortunately, the current implementation of Chrome and FireFox supports this but this behavior is not clearly defined in the spec.

We believe a simple IDL fix won't be enough to explain, so we need to come up with a short prose for it.

Thanks for pointing that out!

We have a plan to add steps to consume processorOptions in AudioWorkletProcessor constructor (which is super() call):
https://webaudio.github.io/web-audio-api/#AudioWorketProcessor-constructors