Intent to Implement: AudioWorklet

[Hongchan Choi]

Contact emails

hong...@chromium.org, rt...@chromium.org

Spec

https://webaudio.github.io/web-audio-api/#AudioWorklet

Summary

The AudioWorklet object allows developers to supply JavaScript code to process audio on the rendering thread, supporting custom AudioNodes. This processing mechanism ensures the synchronous execution of the script code with other built-in AudioNodes in the audio graph.

Motivation

The ScriptPrcocessor caused several issues (i.e. audio glitch, latency and flooding the main thread) so AudioWG decided to deprecate it over the new AudioWorklet API, that ensures the synchronous audio processing of the user-supplied JS code along with the native parts of Web Audio API.

This has been the most anticipated WebAudio feature from the dev community.

- crbug.com/469639 (36 stars)

- https://github.com/WebAudio/web-audio-api/issues/113 (221 comments)

Interoperability risk

Firefox: Public support (bugzilla entry)

Edge: No public signals

Safari: No public signals

Web developers: Positive (See links in Motivation)

Compatibility risk

This is a new feature, so it does not introduce any compat risk.

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms?

Yes.

OWP launch tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=469639

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/features/4588498229133312

Requesting approval to ship?

No.

[Domenic Denicola]

Hi Hongchan,

From: Hongchan Choi [mailto:hong...@chromium.org]

> Spec
> https://webaudio.github.io/web-audio-api/#AudioWorklet

I know we've communicated before on how to design this, but I just wanted to make sure you were aware that the spec as it stands is not in a state that could be interoperably implemented by multiple user agents. Notably, it doesn't actually have any normative spec text and algorithms, just vague descriptions of what the methods should do; and the IDL has several problems that make it not usable as-is.

I imagine you plan to work through these aspects of the spec as you implement, using implementation feedback to guide the process. That makes sense to me; after all, this isn't an intent-to-ship. But I filed a number of issues at https://github.com/WebAudio/web-audio-api/issues/created_by/domenic which could be helpful in working on this feature and in attempting to improve the interop risk when that time comes.

Best,
-Domenic

[Hongchan Choi]

Thanks Domenic,

I am still addressing issues you raised via the issue tracker. One of them is using the normative spec text and algorithms. My first attempt on that end is currently under the review. I sent out the intent simply because I am starting to work on the exploratory implementation in Blink under the experimental flag. However, I can definitely withdraw the intent and come back later when the spec work is completely stable.

Best,

-Hongchan

[Domenic Denicola]

From: Hongchan Choi [mailto:hong...@chromium.org]

> I am still addressing issues you raised via the issue tracker. One of them is using the normative spec text and algorithms. My https://github.com/WebAudio/web-audio-api/pull/945 on that end is currently under the review. I sent out the intent simply because I am starting to work on the exploratory implementation in Blink under the experimental flag. However, I can definitely withdraw the intent and come back later when the spec work is completely stable.

Oh, sorry, I didn't mean to imply you should withdraw the intent! It makes sense to work on implementation while the spec is still in progress. These are just things that should be addressed before the intent to *ship*.

I'll check out https://github.com/WebAudio/web-audio-api/pull/945; I'm sorry I didn't see that before filing the issues!

[Hongchan Choi]

Thanks for the feedback! The list is super helpful and I'll address them soon.

[Rick Byers]

I'm excited to see this moving along.  IMHO providing primitives for performance isolation is a key part of making it possible for web developers to reason about performance in large apps composed of many pieces.  I expect that (like Compositor Worker now AnimationWorklet) it'll take a bunch of experimentation, debate and consensus building until we're really comfortable enough with the cost/benefit tradeoff of permanently adding this power to the web, but I'm optimistic that's it an achievable goal!