hi there. is ThreadPool apropiate to use to drive a multithreaded audio engine (even inside another plugin)?
its a bit too early to test it myself, as there is no running application yet. i’d like to hear your oppinion if possible, so i can use it while developing the engine.
thanks
jm
Well, no, I wouldn’t have thought it’s relevant at all. A thread pool is for running a large number of discrete jobs on a smaller number of threads. You’d need a much more specialised system to do audio processing.
thanks man! i appreciate your input.
i just figured it out myself a few minutes ago, wanted to post here before wasting your time…too late i guess. sorry for that.
i just made an abstract base for a multithreaded rendering network.
i may even be able to implement it in my current project today(!)… i thought it would be more of a headache…we’ll see how it pans out…i have to test it first i guess. looks good so far thought…
peace…and thanks again!!
jm
would be interesting to see your work. i am also thinking to do something like that, do distribute the audio processing of all plugins on several cores. it seems not an easy task: how do you know which plugin will use how much cpu in advance? ofcourse you can’t. you could just put half of the plugins on one and the other half on another core, but it’s not optimal. what’s the best approach to attack this problem? any good strategy advice much appreciated!
Hi zamrate,
I was working on that too. But I want to put the rendering of one plugin on the available cores, not different plugins on different cores.
I have a dualcore, able to do 2 threads at once, I put the rendering of half of the voices in a new class derived from Thread and let the other half of the voices in the main thread. The OS (here win xp) is moving the new Thread automatically to the other CPU and the rendering-time is going down to the half (before 60 voices 70%, with the second Thread 60 voices about 37%, with switched off virus-prg and switched off Task-Manager). But I do have some problems with crackling. Right now I haven’t had the time to figure out if there is a mistake in my implementation (waitableevent,criticalsection,or elsewhere) or if the solution itself will not work. Also it could be that you should only use one thread less than you have cpu’s, so that one cpu can always be occupied from the OS or other programs and you don’t have to wait until it is free.
I think 1 thread less than number of cpus/cores makes sense. Also, bare in mind that the other worker thread should have a high priority. It should actually be pretty straightforward to implement.
