Closed bzbarsky closed 5 years ago
I think we wanted to make it clear to authors that this was an error caused in the audio rendering thread (In the AudioWorkletGlobalScope
): an error in the DSP code.
Or for an error during the AudioWorkletProcessor construction.
Like I mentioned, we need to expose ErrorEvent
to AudioWorkletGlobalScope.
Related: https://github.com/WebAudio/web-audio-api/issues/1846 https://github.com/WebAudio/web-audio-api/issues/1282
This is a known issue without a clear solution. I still believe this should be a part of the Worklet infra. Cross-thread posting an error to AudioWorkletNode is more of a bonus.
To be clear, this bug is about the fact that the actual event that gets fired is not clearly defined.
There's a separate problem, handled by other issues, that what causes the event to get fired is not clearly defined at the places where that causation would occur...
Like I mentioned, we need to expose
ErrorEvent
to AudioWorkletGlobalScope.
I assume the previous mention was in response to the similar ErrorEvent question asked at https://github.com/WebAudio/web-audio-api/issues/1282#issuecomment-384102199.
onprocessorerror
is in Window scope and so an ErrorEvent would be fired in Window scope.
Wouldn't it be possible to create an ErrorEvent in Window scope instead of creating in AudioWorkletGlobalScope in order to be serialized/copied to be fired in Window scope?
The inability to clone errors for ErrorEvent.error may still make things a bit tricky. I don't know the best way to deal with that.
The inability to clone errors
Fixed in specs; see https://github.com/whatwg/html/issues/4268
Implementation support is unclear so far, but presumably will be added at some point.
Also, you can fire an ErrorEvent with a null .error
but still a useful .message
.
onprocessorerror is in Window scope and so an ErrorEvent would be fired in Window scope. Wouldn't it be possible to create an ErrorEvent in Window scope instead of creating in AudioWorkletGlobalScope in order to be serialized/copied to be fired in Window scope?
I find it weird that firing an ErrorEvent
on the main global scope when the actual error happens in the WorkletGlobalScope. From the main thread view point, something bad happened in the audio thread so it just needs a warning or a notification, not a world-stopping exception.
Firing an ErrorEvent
is not a world-stopping exception.
Also, we're not talking about firing an ErrorEvent
on the global in the Window scope. We're talking about firing it on the AudioNode
, no? This is exactly "a warning or notification", similar to the way Worker
notifies the main thread about exceptions in the worker...
Thanks for the input. Here's my plan:
When an AudioWorkletProcessor constructor or its process()
method throws, the processor will queue a task to create and fire an ErrorEvent
the main control thread (global window) with the relevant information.
It's still problematic that WorkletGlobalScope doesn't have an error handling channel. The above discussion only applies to the node-processor level error handling.
The plan sounds pretty reasonable to me.
https://webaudio.github.io/web-audio-api/#dom-audioworkletnode-onprocessorerror says:
First, I assume it means that an event of type "processorerror" is fired, even though that's not what it says, right?
Second, is this event just an
Event
or does it implement some other event interface? Is there a reason to not make this anErrorEvent
, and name the attribute "onerror"?