-
Notifications
You must be signed in to change notification settings - Fork 167
Are Float32Arrays in inputs, outputs, and parameters arguments to process() reused between calls or created each time? #2381
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Is this question about AudioWorkletNode or a generic AudioNode case? |
This issue was intended specifically for the Float32Arrays provided to AudioWorkletProcessor.process(). This case is special because this runs on the rendering thread, where I expect that minimizing garbage is preferable. For completeness though, there are two other APIs in the spec that pass Float32Arrays to JS:
AudioBuffer.getChannelData() provides the same object each time in both Chome and Firefox, though that is not clearly specified AFAIK. |
#1933 (comment) suspects a previous resolution based on the reasoning that objects being transferred to another thread would be too much of a problem. I searched old issues and couldn't find such a resolution or discussion. The most recent comment I found was #1127 (comment)
|
This issue has some discussion, so we certainly discussed it in the design process. (@padenot knows) We all are aware that this will affect the GC, but it requires a new mechanism that prevents AWGS-generated (provided by audio subsystem) buffers from being transferred to the other realms. That seems like a non-trivial change, perhaps out of Web Audio API's boundary. Another thought came up was to designate the WASM heap for this purpose, but also not feasible for V1. |
Given there are other APIs that don't specify when a new object is created or reused, it seems acceptable to leave this unspecified for I don't think this needs to be resolved for v1. More specifics could perhaps be added when implementations have had more time to optimize. |
See #1933 (comment) that is relevant to this discussion. |
….process() parameters r=padenot,bzbarsky Objects are retained for re-use so as to reduce garbage generation and other performance benefits. This is currently unspecified. https://github.com/WebAudio/web-audio-api/issues/1934 WebAudio/web-audio-api#1933 WebAudio/web-audio-api#1935 tracks specification of zero-channels of input when inputs are not actively processing. Differential Revision: https://phabricator.services.mozilla.com/D34836 --HG-- extra : moz-landing-system : lando
….process() parameters r=padenot,bzbarsky Objects are retained for re-use so as to reduce garbage generation and other performance benefits. This is currently unspecified. https://github.com/WebAudio/web-audio-api/issues/1934 WebAudio/web-audio-api#1933 WebAudio/web-audio-api#1935 tracks specification of zero-channels of input when inputs are not actively processing. Differential Revision: https://phabricator.services.mozilla.com/D34836
This is being handled in #1933. The answer to the question asked in this bug is "inputs, outputs and parameters are reused between calls". 1933 doesn't have prose yet, but there is agreement between implementers, and we to test implementation before writing the text. The outcome of this issue will not change however, objects are reused. |
This was originally filed as #1127 but the resolution is not clear to me.
https://webaudio.github.io/web-audio-api/#rendering-loop has
which implies that the "input buffer" used to "invoke processFunction" is a new object for each invocation. Is that the intention?
https://heycam.github.io/webidl/#es-sequence indicates that IDL
sequence<T>
types correspond to ECMAScript Array values. Conversion to ECMAScript values produces a new Array object, so the Arrays are new objects each time, if process() is invoked as a WebIDL callback. However, the Float32Array elements of these arrays could still either be reused or created each time, because they are not copied on conversion.The text was updated successfully, but these errors were encountered: