[audioworklet] Add `state` and related event handlers in AudioWorkletNode

[hoch]

Motivation: #1193 (comment)

The propose IDL is:

enum AudioWorkletProcessorState {
  "created",
  "running",
  "stopped",
  "error"
};

interface AudioWorkletNode : AudioNode {
  readonly attribute AudioParamMap parameters;
  readonly attribute MessagePort port;
  readonly attribute AudioWorkletProcessorState processorState;
  attribute EventHandler onprocessorstatechange;
  attribute EventHandler onprocessorerror;
}

In this way, user can inspect the current status of AWN more easily. More importantly, the construction of AWN/AWP is now asynchronous, thus the failure in the processor construction will notify the node via onerror event handler and render the node inactive state, resulting the silent output.

[padenot]

When defining a state machine, I find it useful to describe the legal transitions and what causes those transition.

Is this new member reflecting the state of the AWP or the AWN ? This state seems synchronized, in an asynchronous fashion, but I think this enumeration describes the state of the AWP: You can't really put the main thread AudioNode in error, or have it in running state, etc., it's just a proxy that sends messages to the AWP, that does the real work and can fail an run and stop and the like.

With that in mind, I would name the enum AudioWorkletProcessorState, and it would live on the AudioWorkletNode indeed.

[hoch]

@padenot Good point. Updated the IDL accordingly.

Asking to @rtoy and @joeberkovitz as well: how about the enum entries? Will 4 states above good enough? Do we need more or less?

[padenot]

When is it "stopped"? When the AudioContext is suspended ?

[hoch]

Here are informal descriptions for each state:

• created
  • The processor is created but process() has not been invoked. This is the initial state after the successful construction of a processor.
• running
  • As long as process() returns true the processor maintains this state. This check is performed at the end of render quantum.
• stopped
  • When process() returns false.
• error
  • When the invocation of constructor(), process() or any user-defined processor method throws an exception.

For the state event handling:

• The state is changed at the end of each render quantum.
• The processor state change will queue a task on the main thread to fire an onprocessorstatechange event to the corresponding AudioWorkletNode.

[padenot]

Looks good.

[joeberkovitz]

@hoch don't we need a state that reflects the period before the AWP has been created? Since AWP construction is now asynchronous, this state would let the application know that...

• all messages to the AWP will be queued
• no audio processing can happen (whereas created just means no audio processing has happened)

[hoch]

@joeberkovitz Should we change created to pending or add pending to the enum entries? Having too many state indicators is something that I want to avoid, but it is what it is.

[rtoy]

If stopped is the same as when process() returns false, is it really necessary then?

[hoch]

If you want to inspect the processor's state from the main thread, I think it is necessary. The return value from process() lives on the rendering thread.

[joeberkovitz]

A few points:

1. I think pending is a distinct state (and this is a good name). It precedes creation.

2. I think we should replace the trio of created, running and stopped with 2 states: active ( AWP has been created, with active source flag true) and inactive (AWP has been created, but active source flag has been updated to false).

Note that the active source flag is already defined in the spec. It is initially true on creation, and is updated to reflect the most recent return value from process(). Note that process() is called even for an inactive AWP if there are any connected inputs to the node, which can set the active source flag back to true again.

[hoch]

Yes, I overlooked the internal flags. I guess we have to utilize these two state flags in conjunction with the exposed state property somehow. Only concern of mine on using terms like active or inactive is that the user can get easily confused by abstract property names.