You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm requesting a TAG review of AudioContext.onerror.
Report a failure from acquiring system audio resources and audio rendering errors to web applications via a callback assigned to AudioContext.onerror.
Explainer¹ (minimally containing user needs and example code): N/A
This is a small change. So I figured doing it inline.
Currently there is no way for the user's agent to know if their AudioContext has failed either at creation (instantiation of AudioContext) or while rendering. At such failure, the web application silently acts as though audio is working correctly even though it's not.
Having AudioContext know of the platform's AudioDestination rendering failure will enable the developers to plan a recovery. This design proposes adding the event attribute onerror to the existing WebAudio API class AudioContext. The user's agent will call that at failures.
The group where the incubation/design work on this is being done (or is intended to be done in the future): W3C Audio Working Group and W3C Audio Community Group
The group where standardization of this work is intended to be done ("unknown" if not known): W3C Audio Working Group and W3C Audio Community Group
Hi @gsinafirooz, thanks for filing this. What we can see looks reasonable, and we think that a more thorough review isn't warranted. Given that this is so small we're going to defer to the working group for this.
Also, we wanted to point out that we have Q & A section exactly for these types of smaller scope API design questions that is meant to be lighter process-wise than a design review.
こんにちは TAG-さん!
I'm requesting a TAG review of AudioContext.onerror.
Report a failure from acquiring system audio resources and audio rendering errors to web applications via a callback assigned to AudioContext.onerror.
Explainer¹ (minimally containing user needs and example code): N/A
This is a small change. So I figured doing it inline.
Currently there is no way for the user's agent to know if their
AudioContext
has failed either at creation (instantiation ofAudioContext
) or while rendering. At such failure, the web application silently acts as though audio is working correctly even though it's not.Having
AudioContext
know of the platform'sAudioDestination
rendering failure will enable the developers to plan a recovery. This design proposes adding the event attributeonerror
to the existing WebAudio API classAudioContext
. The user's agent will call that at failures.User research: https://docs.google.com/presentation/d/1DNjlh_JwjfwDzoULAUx5wUj2Igrx-eUbZ2ZHltLGOZo/preview?slide=id.g9bcfd5e720_0_18
That's our top un-shipped feature request.
Security and Privacy self-review²: N/A
GitHub repo (if you prefer feedback filed there): https://github.com/WebAudio/web-audio-api
Primary contacts (and their relationship to the specification):
Organization/project driving the design: Google
External status/issue trackers for this feature (publicly visible, e.g. Chrome Status):
Further details:
The text was updated successfully, but these errors were encountered: