Intent to Ship: AudioWorklet

168 views
Skip to first unread message

Hongchan Choi

unread,
Feb 13, 2018, 3:55:53 PM2/13/18
to blink-dev, cwi...@chromium.org, Joshua Bell, Ian Kilpatrick, Hiroki Nakagawa

Contacts emails

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


Design Doc/spec


Summary

The AudioWorklet exposes low-level audio processing to web developers within Web Audio API's ecosystem. It is designed to address the architectural flaw of  ScriptProcessorNode; AudioWorklet offers low latency, runs on render thread and empowers developers with extensible interface.


Link to intent to implement and experiment

Blink-dev Intent to Implement: AudioWorklet

Blink-dev Intent to Experiment: AudioWorklet


Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes


Selected demos


Risks

Interoperability and Compatibility Risk


Is this feature fully tested by web-platform-tests?

Not yet. The existing tests in Chromium are fully compatible with web-platform-tests, and will be be upstreamed to WPT once the feature is enabled by default.


Entry on the feature dashboard

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

https://developers.google.com/web/updates/2017/12/audio-worklet

https://blog.chromium.org/2017/12/chrome-64-beta-stronger-pop-up-blocker_14.html


Hongchan Choi

unread,
Feb 15, 2018, 12:33:14 PM2/15/18
to blink-dev, cwi...@chromium.org, Joshua Bell, Ian Kilpatrick, Hiroki Nakagawa
From today's AudioWG teleconference, Microsoft indicated the positive signal on the implementation of AudioWorklet:

Philip Jägenstedt

unread,
Feb 21, 2018, 8:33:55 AM2/21/18
to Hongchan Choi, blink-dev, cwi...@chromium.org, Joshua Bell, Ian Kilpatrick, Hiroki Nakagawa
LGTM1, pretty exciting to see a replacement for ScriptProcessorNode :)

Will AudioWorklet share the same mechanism that PaintWorklet uses to switch between multiple global objects in a non-deterministic way, to make it impossible to depend on global state? Or does an AudioWorklet simply life for the lifetime of the AudioContext so that it's just fine to depend on global state persisting in this case?

Note that it's fine to put test in WPT even before the feature is enabled (or even implemented) in any browser, so upstreaming those independently of this intent would be great.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGJqXNvqSoRPnhF5k-fULbQeM4PMHi%2BkJ%3D_v8SPERYZ8Knu4LQ%40mail.gmail.com.

Hongchan Choi

unread,
Feb 21, 2018, 11:22:26 AM2/21/18
to Philip Jägenstedt, blink-dev, cwi...@chromium.org, Joshua Bell, Ian Kilpatrick, Hiroki Nakagawa
Thanks for taking a look, Philip!

> Will AudioWorklet share the same mechanism that PaintWorklet uses to switch between multiple global objects in a non-deterministic way, to make it impossible to depend on global state? Or does an AudioWorklet simply life for the lifetime of the AudioContext so that it's just fine to depend on global state persisting in this case?

We (AudioWG) are aware of PaintWorklet's case, but we have decided not to follow PaintWorklet's precedence. As you already pointed out, AudioWorkletGlobalScope's lifetime is tied to the associated AudioContext. Being able to use global state can be very useful for storing WASM module. 

> Note that it's fine to put test in WPT even before the feature is enabled (or even implemented) in any browser, so upstreaming those independently of this intent would be great.

Sure, I will start working on it then.

Rick Byers

unread,
Feb 21, 2018, 4:59:10 PM2/21/18
to Hongchan Choi, Philip Jägenstedt, blink-dev, cwi...@chromium.org, Joshua Bell, Ian Kilpatrick, Hiroki Nakagawa
LGTM2

Looking through the open spec issues and talking offline it looks like there are two which likely need to be resolved before shipping: currentFrame and AudioWorkletProcessorState (both under active discussion).  As always, if the WG fails to reach consensus on issues like these which could have future compat implications, please either revert enabling the feature before it hits Chrome stable, or circle back on this thread to discuss.

Rick

Hongchan Choi

unread,
Feb 21, 2018, 5:18:38 PM2/21/18
to Rick Byers, Philip Jägenstedt, blink-dev, cwi...@chromium.org, Joshua Bell, Ian Kilpatrick, Hiroki Nakagawa
Thanks for the review, Rick!

I will report back once AudioWG has the resolution on those two issues. With that said, I do not expect anything controversial there.

-Hongchan

Ojan Vafai

unread,
Feb 22, 2018, 2:39:40 PM2/22/18
to Hongchan Choi, Hiroki Nakagawa, Ian Kilpatrick, Joshua Bell, Philip Jägenstedt, Rick Byers, blink-dev, cwi...@chromium.org

Hongchan Choi

unread,
Feb 22, 2018, 2:40:29 PM2/22/18
to Ojan Vafai, Hiroki Nakagawa, Ian Kilpatrick, Joshua Bell, Philip Jägenstedt, Rick Byers, blink-dev, cwi...@chromium.org
Thank you all for the review!

pad...@mozilla.com

unread,
Feb 23, 2018, 1:50:33 PM2/23/18
to blink-dev, cwi...@chromium.org, jsb...@chromium.org, ikilp...@chromium.org, nhi...@chromium.org
I'm a bit late to the party, but as noted, Mozilla intends to implement and ship this feature, hopefully soon.

Thanks,
Paul.

Hongchan Choi

unread,
Feb 23, 2018, 2:03:27 PM2/23/18
to pad...@mozilla.com, blink-dev, cwi...@chromium.org, jsb...@chromium.org, ikilp...@chromium.org, nhi...@chromium.org
Thanks for the comment, Paul. AudioWorklet now has 3 LGTMs, so we are preparing for the launch. Looking forward!

-Hongchan


--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
Reply all
Reply to author
Forward
0 new messages