Intent to Ship: AudioWorklet

[Hongchan Choi]

Contacts emails

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

Design Doc/spec

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

• TAG review: https://github.com/w3ctag/design-reviews/issues/212

• Design doc: https://goo.gl/5a19Qv

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

• https://googlechromelabs.github.io/web-audio-samples/audio-worklet/
  (by Chrome WebAudio team)

• https://www.webaudiomodules.org/wamsynths/

• https://wasabi.i3s.unice.fr/pedalboard/

• http://faust.grame.fr/news/2017/12/12/benchmark-tools.html

• https://node.charlieroberts.cricket/playground/

Risks

Interoperability and Compatibility Risk

• Interoperability Risk: Moderate. The majority of AudioWorklet spec has been finalized and the review from the TAG was positive. Audio WG is currently discussing minor edits, but we expect them to be resolved before the launch.

• Edge: No public signal (bug assigned)

• Firefox: Public support (bug assigned)

• Safari: No public signal

• Web developers: Positive.

• Some positive feedback from Origin Trial participants can be found in https://crbug.com796330.

• External links
  http://www.webaudioweekly.com/84
  https://frontendfoc.us/issues/319
  https://www.audiotool.com/board/news/chrome_audioworklet
  https://qiita.com/ryoyakawai/items/1160586653330ccbf4a4
  https://weblike-curtaincall.ssl-lolipop.jp/blog/?p=2027

• Compatibility Risk: None, adding a new primitive to the web platform.

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]

From today's AudioWG teleconference, Microsoft indicated the positive signal on the implementation of AudioWorklet:

https://www.w3.org/2018/02/15-audio-minutes.html

[Philip Jägenstedt]

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]

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]

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGJqXNt-aRj40SfxO6KLk1oHUAp4mhQyT8L4F1C5MivogBFKNg%40mail.gmail.com.

[Hongchan Choi]

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]

Lgtm3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGJqXNsZmJL2yAKbk2CHqkZ4xcP%2BkBf6QeShCqY35orHLTdzcQ%40mail.gmail.com.

[Hongchan Choi]

Thank you all for the review!

[pad...@mozilla.com]

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]

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2aa28d8a-11cb-4f42-9890-073011a819b4%40chromium.org.