← Back to release summary

Shared MessagePort for AudioWorklet

Category
Multimedia
Type
Chromium catches up
Status
Proposed (Chrome Proposed)
Intent stage
None

WPT details: https://wpt.fyi/results/webaudio/the-audio-api/the-audioworklet-interface/audioworklet-messageport.https.html

Summary

Exposes a shared MessagePort on AudioWorklet and AudioWorkletGlobalScope. This lets web applications communicate directly between the main thread AudioWorklet and the AudioWorkletGlobalScope without creating a bootstrap AudioWorkletProcessor only for message passing.

Motivation

The Web Audio specification defines a shared MessagePort on AudioWorklet and AudioWorkletGlobalScope. This lets web applications communicate directly between the main thread and the AudioWorkletGlobalScope without creating a bootstrap AudioWorkletProcessor or AudioWorkletNode only for message passing. Without this capability, developers have to keep workaround code that instantiates dummy processors solely to transfer initialization data or control messages into the worklet global scope. This adds code complexity and runtime overhead, and prevents cleanup of compatibility hacks in upstream projects. This change aligns Chromium with the current Web Audio specification and existing interoperable behavior. It also restores compatibility for real-world code that expects audioContext.audioWorklet.port to exist, including Emscripten-generated applications and demos such as the MOD player discussed in the linked issue. Relevant specification and ecosystem discussion: - https://github.com/WebAudio/web-audio-api/issues/2456 - https://github.com/WebAudio/web-audio-api/pull/2507 - https://github.com/emscripten-core/emscripten/pull/25354

Standards & signals

Ecosystem

Docs: https://developer.mozilla.org/docs/Web/API/AudioWorkletGlobalScope/port

Explainers: https://github.com/WebAudio/web-audio-api/issues/2456 https://github.com/WebAudio/web-audio-api/pull/2507

View on chromestatus.com