search

WebAudio / web-audio-api-v2

The Web Audio API v2.0, developed by the W3C Audio WG
Other
120 stars 11 forks source link

Ability to access computedValue of AudioParam #51

Closed Smilebags closed 4 years ago

Smilebags commented 5 years ago

Describe the feature Add computedValue readonly property to AudioParam.

Is there a prototype? I attempted to create an AudioWorkletNode which assisted with this but wasn't able to achieve anything useful since there is also no getter for the current computedValue of an AudioNode, and using the MessagePort available was either too intensive or too high latency, and timing too unpredictable to be considered a suitable workaround.

Describe the feature in more detail It seems that previous inconsistent implementations of the getter on AudioParam.value in Chrome (which retrieved the computed value after summing any connected inputs) has been removed, in order to follow the spec which states it should return the current interpolated value based on the current automation event (AudioParam.linearRampToValueAtTime for example).

As stated in WebAudio/web-audio-api#1788, the AudioParam.value getter is often used to drive visual representations of the parameter, which means incorporating any inputs' contributions is desired. While I understand the need and reasoning behind going with the decision made in WebAudio/web-audio-api#1788, access to the computed value is still very much needed. As far as I can tell there is no straightforward way to access this value anymore.

As suggested in WebAudio/web-audio-api#1788, a readonly property of AudioParam (and ideally AudioNode too) called computedValue would solve this without introducing ambiguity into the current spec of setters and getters behaviour.

It was brought up that performance concerns might arise depending on the implementation, which is reasonable, but considering those performance issues would have existed in any previous implementations that did this, I don't see this as a major issue. Users of the API will realise if computedGetter causes performance issues and find a workaround if one exists for them, but in many cases, such a getter might be called 60 times a second or less, certainly not at audio rates - performance might not be a great concern for many users of the API, including myself.

padenot commented 5 years ago

Have you tried using a SharedArrayBuffer to implement this? It's essentially what implementations would do anyways. In any case, we won't be addressing this in V1, so I'm moving this to the other repo.

Smilebags commented 5 years ago

Thanks for the quick reply. I'll take a look using a SharedArrayBuffer with an AudioWorkletNode, if I can achieve it with that it'll be very helpful, though I'm concerned it might be difficult to get it precise.

While this isn't going to be added to V1, is it under consideration for future inclusion? Working with a property which 'just works' is much more straightforward than spinning up a new thread and using a shared array buffer in order to access the same value.

padenot commented 5 years ago

Thanks for the quick reply. I'll take a look using a SharedArrayBuffer with an AudioWorkletNode, if I can achieve it with that it'll be very helpful, though I'm concerned it might be difficult to get it precise.

It will be as precise as it can be, since it's going to be shared memory with atomics.

While this isn't going to be added to V1, is it under consideration for future inclusion? Working with a property which 'just works' is much more straightforward than spinning up a new thread and using a shared array buffer in order to access the same value.

Yes, I moved it to our v2 repo, as you can see. Also this is not going to spin up any extra thread.

padenot commented 4 years ago

Virtual F2F:

padenot commented 4 years ago

Closing in light of the above, the group feels it's an adequate answer in terms of performance.

Smilebags commented 4 years ago

Thanks, I was able to achieve what I needed with the regular postMessage behaviour, since driving the UI is not required to be perfectly latency-free.