ACTION-92: Report on exploration of performance impact of github issue 268
Report on exploration of performance impact of github issue 268
- State:
- closed
- Person:
- Chris Wilson
- Due on:
- February 20, 2014
- Created on:
- December 19, 2013
- Related emails:
- No related emails
Related notes:
[olivier]: cwilso says he has looked into it with Ray and Alex. Should be doable but makes the problem with scriptprocessor even worse
6 Feb 2014, 17:10:52Forgot 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.
Display change log.