search

WebAudio / web-audio-api

The Web Audio API v1.0, developed by the W3C Audio WG
https://webaudio.github.io/web-audio-api/
Other
1.05k stars 166 forks source link

Is AudioWorkletProcessor.process supposed to be stateless? #2272

Closed carlsmith closed 3 years ago

carlsmith commented 3 years ago

I found the spec ambiguous, as though it wants to mandate that code in AudioWorkletProcessor.process should be stateless, but never actually requires it explicitly.

It begs the question why the API is object oriented if it was intended to encourage stateless implementations. Anyway, audio nodes are often intrinsically stateful. The predefined nodes of the API include examples.

rtoy commented 3 years ago

Can you point out what part of the spec lead you to believe it's stateless?

I have not actually tried it out, but have thought about it, but I think it would be possible to polyfill every AudioNode with an AudioWorklet. But we've also discovered there are some things that can't work today with an AudioWorklet, like changing the number of output channels, except in very special cases.

carlsmith commented 3 years ago

I'm struggling to find everything I read before, but I did read the WebAudio API again, and it does not (even implicitly) require statelessness, anywhere.

However, in the official spec for Worklets, in Section 1.2 (Code Idempotency) and Section 1.3 (Speculative Evaluation) it is actually explicit that "authors who register classes on the global scope using these [Worklet] APIs, should make their code idempotent... [and] stateless".

It only mentions the css-paint-api-1 (twice) as an example of an API that takes advantage of the statelessness, but seems to require it for all users of Worklet-based APIs.

To be honest, I think I read that and the WebAudio spec (and maybe something else), and just conflated them. Still, the Worklets spec does seem to be at odds with the WebAudio spec.

carlsmith commented 3 years ago

From Section 1.3 of the Worklet spec:

In these specifications user agents might invoke methods on a class at any time, and with any arguments, not just ones corresponding to the current state of the user agent. The results of such speculative evaluations are not displayed immediately, but may be cached for use if the user agent state matches the speculated state. This may increase the concurrency between the user agent and worklet threads.

As a result of this, to prevent this compatibility risk between user agents, authors who register classes on the global scope using these APIs, should make their code stateless. That is, the only effect of invoking a method should be its result, not any side-effects such as updating mutable state.

rtoy commented 3 years ago

Thanks for the pointers. I think we do want to be able to polyfill any existing node with an AudioWorkletNode, so state would be required. I suspect people using a AudioWorkletNode in interesting ways do use state.

padenot commented 3 years ago

You're reading an outdated document, it's unfortunately not obvious. Anything with /TR/ in the URL is usually obsolete (except for recs, maybe).

Worklets are in HTML these days (very recent), here is the section that explains everything (specifically answering the question you have): https://html.spec.whatwg.org/multipage/worklets.html#worklets-motivations (last paragraph).