call AudioWorkletProcessor.process()
Categories
(Core :: Web Audio, enhancement, P2)
Tracking
()
People
(Reporter: karlt, Assigned: karlt)
References
Details
Attachments
(6 files)
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
bug 1558123 create JSObjects for inputs/outputs AudioWorkletProcessor.process() parameters r?padenot
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details |
Assignee | ||
Comment 1•5 years ago
|
||
This is set in the AudioNodeStream constructor and does not change.
Assignee | ||
Comment 2•5 years ago
|
||
It is easier to make a span than an nsTArray.
This also clarifies that the output array lengths are not modified.
Depends on D34833
Assignee | ||
Comment 3•5 years ago
|
||
Depends on D34834
Assignee | ||
Comment 4•5 years ago
|
||
Objects are retained for re-use to reduce garbage generation and other
performance benefits. This is currently unspecified.
https://github.com/WebAudio/web-audio-api/issues/1934
https://github.com/WebAudio/web-audio-api/issues/1933
https://github.com/WebAudio/web-audio-api/issues/1935 tracks specification of
zero-channels of input when inputs are not actively processing.
Depends on D34835
Assignee | ||
Comment 5•5 years ago
|
||
Direct use of aInput buffers for ArrayBuffer elements is not possible in
general. aInput buffers are const because they may be used elsewhere but
ArrayBuffer elements may be modified by script. If necessary, it would be
possible to later add a mechanism to mix inputs directly into the ArrayBuffer,
but often no mixing is required.
Direct use of output ArrayBuffer elements would require DetachArrayBuffer to
ensure the elements are not modified by script, but that would require
creation of a new ArrayBuffer JS object on each call.
https://github.com/WebAudio/web-audio-api/issues/1932 tracks specification of
making output data available for reading (for downstream node input).
Depends on D34836
Assignee | ||
Comment 6•5 years ago
|
||
https://heycam.github.io/webidl/#invoke-a-callback-function is not used here
because that would "perform a microtask checkpoint" in "clean up after running
script", which would be in conflict with "Any Promise resolved within the
execution of process method will be queued into the microtask queue in the
AudioWorkletGlobalScope" in
https://webaudio.github.io/web-audio-api/#rendering-loop
See also https://github.com/WebAudio/web-audio-api/issues/1933
There are also some small optimizations possible with using JS::Call() directly:
JS::ExposeObjectToActiveJS() is not necessary because parameters are
PersistentRooted and so won't be gray. MaybeWrapObjectValue() is not
necessary because parameters are already in the appropriate compartment.
Depends on D34837
Assignee | ||
Comment 7•5 years ago
|
||
The patches here are enough to run the example at
https://googlechromelabs.github.io/web-audio-samples/audio-worklet/basic/hello-audio-worklet/
with dom.audioworklet.enabled and dom.worklet.enabled preferences set to true.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=24478da1c4aadb12bd83995cc2125f96dae99925
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Comment 9•5 years ago
|
||
bugherder |
Comment 10•5 years ago
|
||
Comment 11•5 years ago
|
||
bugherder |
Updated•5 years ago
|
Description
•