ACTION-92: Report on exploration of performance impact of github issue 268

[olivier]: cwilso says he has looked into it with Ray and Alex. Should be doable but makes the problem with scriptprocessor even worse

Forgot to capture the conversation from the telecon on Jan 23:

In short, I'm concerned, because although I recognize using new buffers for every onaudioprocess call is the easiest way to fix the race condition possibility in script processors, I note that it will mean every call to onaudioprocess will necessitate likely six memory allocations - the AudioBuffers, plus the channel data in each channel, for input and output. This will mean more memory pressure - particularly on constrained-memory environments like mobile devices - which will increase the likelihood of garbage collection happening, which in turn is more likely to cause audio glitching.

I don't have a clean solution to this, other than perhaps implementing a Worker-based script processor, where at least it would not have the main thread pressure as well; and, in fact, you could perhaps specify that the i/o buffers are tranferred (and therefore neutered, and it would be irrelevant and unnecessary to use new buffers for every call.