You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In some places, Nodes will be part of a straight chain.
In these places, if no other Node is dependant on the input, a Node can simply use the input Node's buffer.
In order to do this, we can check in prepareToPlay if any Nodes in the graph reference input and if not, set the optimisations to "don't allocate". We can then get the source buffer in process and call setAudioOutput instead of filling it.
This is in place in some locations already but the above is an addition that should make it unnecessary to even allocate the memory in the first place.
TrackMutingNode [172] (saves 88,400B)
RackInstanceNode [80] (saves 73,840B) (use source buffers if single output)
ReturnNode [79] (saves 672,880B) (can disable allocation in prepare if there is valid input, otherwise it will be empty)
RackReturnNode [72] (saves 74,880B) (use source buffers if single output)
PluginNode [79] (saves 67,600B) (use source buffers if single output)
LevelMeasurerProcessingNode [21] (saves 21,840)
SummingNode [89]
FadeInOutNode
Other optimisations
SinkNode (can have a shared empty buffer and set this as the output)
ReturnNode [?] (can have a shared empty buffer and set this as the output)
Nodes receiving sink nodes and skip them to avoid adding silence
N.B. The above could have problems if a Node tries to steal its buffer and write over it. We would need some mechanism for preventing this.
The text was updated successfully, but these errors were encountered:
In some places, Nodes will be part of a straight chain.
In these places, if no other Node is dependant on the input, a Node can simply use the input Node's buffer.
In order to do this, we can check in prepareToPlay if any Nodes in the graph reference
input
and if not, set the optimisations to "don't allocate". We can then get the source buffer in process and callsetAudioOutput
instead of filling it.This is in place in some locations already but the above is an addition that should make it unnecessary to even allocate the memory in the first place.
Other optimisations
N.B. The above could have problems if a Node tries to steal its buffer and write over it. We would need some mechanism for preventing this.
The text was updated successfully, but these errors were encountered: