Change ScriptProcessorNode::onaudioprocess API - use owned buffer value

[orottier]

This is easier for the node bindings. We hook into the Drop call of the event to ship the output buffer to the render thread.

TODO: I found a gnarly bug where the ScriptProcessorRenderer would be cleared from the audio graph erroneously. AudioContextRegistration should not be allowed to implement Clone because it has a very meaningful Drop implementation. That's why I now resort to an Arc hack to prevent the Drop method to run.

@b-ma could you check if this solves your issues? I will look into the clone/drop bug of AudioContextRegistration in the meantime

[b-ma]

Unfortunately, not completely...

I'm now able to propagate the event to JS thread safe fnuction, but now the problem is propagated to the AudioBuffer behaviour:

• I need to clone the AudioBuffer which is owned by the rust event to create the JS AudioBuffer
• but then when I write to the output buffer channel data, the inner values are logically cloned...

[b-ma]

Ok, I managed to have something work! cf. https://github.com/ircam-ismm/node-web-audio-api/pull/114/files#diff-f2a3e90afd7d940e52b634347f9a1e12ee21402dafa586f92c960ad13fa052fcR150

Used the std::mem::replace trick to steal the I/O buffers from the event and give them back once the JS function is executed.

The only drawback is that I had to add an alternative implementation of ThreadSafeFunction to the source code which allows to execute rust code before and after the execution of the JS callback, but it seems a far better design than the one provided by napi-rs so it is ok I think

Thanks for the help!

[b-ma]

Just thinking, maybe we could add a AudioBuffer::tumbstone constructor to the public API? This pattern seems really helpful in some situation

[orottier]

Just thinking, maybe we could add a AudioBuffer::tumbstone constructor to the public API? This pattern seems really helpful in some situation

We could, but maybe we should mark it [doc(hidden)] because we will probably run into all sorts of panics and runtime errors when you actually use a zero-channel buffer (in the AudioBufferSourceNode for example)