AudioContext.onerror

[hoch]

This PR resolves #2567.

• Add the onerror event handler under the AudioContext interface.
• Add a step to fire onerror event in the AudioContext constructor steps on the render thread.
• Remove the non-normative notes on the notification being impossible.
• Add a prose to specify the onerror case on a running AudioContext.

---

Preview | Diff

[hoch]

@padenot Ready for the first pass. Let me know what you think!

[gsinafirooz]

Hi @padenot; I just wanted to bump this.

[marcoscaceres]

@jernoble, could you take a look at this also by chance?

[hoch]

@padenot It looks like we resolved all discussions so far. Let me know if you have more questions!

[gsinafirooz]

@jernoble, could you take a look at this also by chance?

@jernoble, We'd like to hear your opinion :)

[hoch]

@jernoble @marcoscaceres Can any of you comment on this pull request? We've been waiting for three weeks, and would like to merge this PR so that we can make progress on the browser implementation.

The PR itself is not really controversial; we want to add an event handler for audio device/platform errors.

[jernoble]

@jernoble, could you take a look at this also by chance?

@jernoble, We'd like to hear your opinion :)

As a comment about the general capability added here, I see no problem with exposing AudioContext error states. This PR appears to be narrowly around handling what happens when the AudioContext loses exclusive access to the current audio sink / device. That either because that device is no longer available permanently (a plug was pulled, a wireless device disappeared, etc.) or because that device is no longer available temporarily (another process / service received exclusive access to that device, etc.). And there's no way to distinguish between those two states here.

In the "permanent" error case, there's nothing for the application to do save choose a different sink. In the "temporary" error case, this is recoverable by simply un-suspending.

Is there some other mechanism available to distinguish these two states? If not, should the onerror handler take a custom Error object with a payload?

[hoch]

that device is no longer available temporarily (another process / service received exclusive access to that device, etc.). And there's no way to distinguish between those two states here.

This is somewhat related `interrupted' status from the AudioSession. Also I am a bit confused by the expression "no longer available" and "temporarily" in one sentence. We have to consider two cases separately.

• If it's temporarily unavailable (as in interrupted) it is not an error. It's an intentional state change initiated by the platform.
• If it's permanently unavailable, that's an error and should be reported by onerror.

[jernoble]

that device is no longer available temporarily (another process / service received exclusive access to that device, etc.). And there's no way to distinguish between those two states here.

This is somewhat related `interrupted' status from the AudioSession. Also I am a bit confused by the expression "no longer available" and "temporarily" in one sentence. We have to consider two cases separately.

That was inelegantly phrased on my part. :)

I was referring to this new language:

• The audio output from a running AudioContext unexpectedly interrupted or the device is disconnected.

What does "unexpectedly interrupted" mean here?

[hoch]

What does "unexpectedly interrupted" mean here?

Yes, now I can see why you used the word "interrupted". Perhaps I can intentionally move away from that language so we can reserve such case for AudioSession API. My example of "unexpectedly interrupted" cases would be any kind of audio infra malfunction reported by the operating system including (but not limited to):

• A wireless device getting disconnected (e.g. too far away from the host machine)
• An external audio device getting disconnected (e.g. USB cable plugged out)

IMO one significant distinction from the AudioSession is:

interrupted: the AudioSession is not playing sound, but can resume when it will get uninterrupted.

The interrupted status can be resumed automatically after the interruption (please correct me if I am mistaken). So I think this can be useful for situations like notification, phone call on mobile device, etc.