your AudioProcessorGraph is really a great tool. Looking at some 20-50 or more plugins being hosted, I wonder if it would make sense to distribute the render work of a graph across multiple CPU cores.
As it is implemented now, the entire chain of render ops is executed on a single thread. For a big graph with many plugins, this could get tight, i.e. the whole chain might not complete within the render block time slice.
In theory, the graph could be splitted into parallel chains, each of which is rendered on a separate thread (thread pool) running on a different CPU core. The final result is then merged from the output buffers of each thread.
As straightforward as this sounds, it is likely a lot more complex. I would expect the hardest part to be the intelligent splitting of the graph, but that could be done manually (programmatically) to some extent. In a typical mixer metaphor, one could split the graph roughly based on channel strips, for example.
Are sub-graphs the best way to implement this, or are there performance penalties that suggest it could be better to implement a specialized graph class?
How would I make sure that threads in a pool are equally distributed across CPU cores?
Am I completely idiotic, missing the most basic things and dreaming of impossible things?
Any thoughts are welcome!