Closed karlt closed 5 years ago
There is no way to restore an ArrayBuffer after detach, so DetachArrayBuffer would be incompatible with permitting the ArrayBuffer to be used on the next call (https://github.com/WebAudio/web-audio-api/issues/1934).
I expect requiring a copy of buffer contents by the implementation would permit a more efficient implementation than requiring a new ArrayBuffer object be exposed to JS on each call.
I expect requiring a copy of buffer contents by the implementation would permit a more efficient implementation than requiring a new ArrayBuffer object be exposed to JS on each call.
We have decided to punt this. See here.
If this issue is solely about rephrasing the text to clarify "making a buffer available for reading", we can talk about it in the next WG teleconf.
We have decided to punt this. See here.
I doubt the direction of https://github.com/WebAudio/web-audio-api/issues/1780 will have much influence on this issue. I don't know whether this is a misunderstanding, or perhaps a different link was intended.
If this issue is solely about rephrasing the text to clarify "making a buffer available for reading" [...]
Yes, thanks. This is about clarifying that the buffer is made available for reading, and what effects, if any, that might have. Decisions made here depend on the resolution of https://github.com/WebAudio/web-audio-api/issues/1934
Yes, thanks. This is about clarifying that the buffer is made available for reading, and what effects, if any, that might have. Decisions made here depend on the resolution of #1934.
Since I have you here @karlt, could you propose the change that you want to see in the spec? We can build up and expand based on your suggestion.
Perhaps the simplest solution would be to add the following after the "invoke processFunction" sentence:
Make available for reading a buffer containing copies of the elements of the Float32Arrays passed via the
outputs
parameter toprocessFunction
.
Thanks! I'll write up a PR.
The rendering loop omits making a buffer available for reading in the case when
IsCallable(argument=processFunction)
returns true. I assume "output buffer" from calling process() on AudioWorkletProcessor should be made available for reading.Perhaps this is implied by "The output audio buffer that is to be consumed by the user agent", but the meaning of "consumed" is not clear.
"putting it in a state where other AudioNodes connected to this AudioNode can safely read from it" implies DetachArrayBuffer, but it would be better to clarify this, because it is observable. This would be consistent with acquiring the contents of AudioProcessingEvent.outputBuffer after dispatch, so that downstream processors can read from the same buffer, without the need for a copy.