Web-audio-api: [TAG] How to handle an exception in AudioWorkletProcessor.process()?

[hoch]

What happens if an exception is thrown inside the worklet while processing audio? Anything? Nothing?

The issued is raised by @slightlyoff at #869.

[hoch]

Currently our spec does not have the process-invalidation process, but I am working on a PR for that. It will be similar to this: https://www.w3.org/TR/css-paint-api-1/#paint-invalidation

In short, if the validation fails for process() method (i.e. an exception thrown), the UA will invalidate the process call by marking it as 'invalid' and the processor will output silence (or bypass) afterward.

[padenot]

That leaves the question, silence or bypass ?

I think I lean towards silence:

• The metaphor makes sense: if something is broken, it stops making sound
• It's more discoverable: say you're writing a worklet that make a subtle change to the sound, it could take a while before being noticed. A message in the developer tools and silence would make it a better experience.
• It's safer: say your worklet is a brick-wall limiter or another device that reduces the volume, and is connected directly to speakers or headphones, bypassing could be quite dangerous.

[hoch]

A message in the developer tools

Not sure if this can be specced? I completely agree that UA needs to provide this.

Similar to PaintWorklet, AudioWorkletNode definition should have a validation flag. Any exception in the constructor() and process() method will flip this flag and the node will produce silence afterwards.

[padenot]

Just an informative note would do in this case, I suppose. Gecko logs thing in the dev console rather liberally when something happens that is not synchronously detectable (so we can't throw an exception right away), but hard to debug (for example, piping an HTMLMediaElement to an AudioContext that is not from the same origin and would produce silence).