There is an excellent discussion of multi core processing (and why GP does not explicitly make use of it) under another topic.
I’d ask anyone reading this post to read the other post first.
Despite that discussion, I have an unanswered question. I can see why GP avoids the trouble of figuring out whether a rackspace can or cannot be divided into multiple threads. However, I can’t understand why multiple instances wouldn’t use separate threads and cores. Can anyone explain why that is difficult or undesirable?
This is an important topic to me, since I would like to use one PC as the audio source for up to 32 tracks of audio output, including four stereo synth channels, 8 drum channels, plugins for voices and guitars, tracks and clicks… all through a single USB connection to my mixer. I’m also trying to keep latency low. (128 or below, ideally.)
I am currently using an old PC (i7-3660, 16GB 1333 Ram, SSD) and I can quite easily overtax the system within the synth tracks alone. I still need to do some performance tweaking to see what the old (free!!) system is capable of… but even if I build myself a truly modern, powerful machine, I fear the processor may give up well before I do. It’s difficult to calculate how much of my scheme is possible without spending the cash up front.
So of course this is where multi threading comes in. Given that I will have entire instances with no interdependencies, would this not be an ideal use case for multi threading?
I’m also curious about this as I plan my CPU build. I assume the current GP topography would perform best on a top-end i7 or i9; but a multi-instance multithreaded version might run best on an AMD Ryzen Threadripper or similar. (Macs aren’t in the equation right now, although I do own and love Mac products.)
I’d love some advice on my build, as well as any comments on my multithreading question.
I am not sure if multi threading is possible for a live system without introducing unwanted latency issues.
By the way: Are you talking of multithreading or using more than 1 core for Gig Performer?
The conventional wisdom on Windows systems is that you’ll maximize audio/DAW/GP performance using a processor with the highest clock speed, all else equal, rather than number of cores or threads. Real world test results tend to vary, however, and in the end tend to be highly dependent on the details of your system, what else is running on it, and what exactly you’re trying to do.
I’ve gone down this path before, and I don’t think you’re going to find a simple answer for any of it. Once you have a configured system, you can experiment and see what works and doesn’t work on your system. For example, you can check whether enabling or disabling hyperthreading helps or hurts your situation. You can test whether splitting loads across multiple instances (or multiple programs) buys you anything.
Last time I did this I found it inconclusive. I know that’s not very useful. The real issue for me is that my main audio system handles whatever I realistically want to throw at it very well, as long as I don’t have too many windows open. That’s the real killer on that system. Leaving the Total Mix FX window open, or a Melda plugin window open, dominates all the other adjustments. So my real lesson is “don’t run a 4k monitor and leave pretty windows open” and “don’t turn on the second monitor if you’re not using it.”
And allowing Google Chrome to run it’s half dozen memory intensive processes in the background is also a glitch-maker for me. What’s really irritating with that one is they keep running forever, even after you close Chrome, and Chrome will configure them to run on startup even if you never start Chrome.
I can see separate threads (or cores) to separate audio and graphics processes. But with respect to the audio itself, multiple threads yield no benefit end-to-end…“you’re only as good as your slowest process (or thread or core)”. After the audio has been processed via multiple threads or cores, it still has to be serialized to be “played back” or heard in its proper order.
Higher clock speed and more RAM yields more báng for the bùck…unless I’ve missed a major technological change over the last decade…
Where did you read that? As far as I know, separate GP instances are run in separate processes so the OS can in fact schedule them across multiple cores.
Yes, but the audio in each instance “stays” in each instance. Well, then, in this regard, I can see each instance on its own thread…but it is possible that the audio stream in one thread might be slightly ahead or behind (i.e., out of sync with) the audio stream in the other thread (OK, probably by a few milliseconds, lol ).
Still trying to wrap my head around this. If I’m playing synth, and I’ve got a layered sound that takes up nearly a full core of processing, and my drummer is playing back sounds from Superior drummer in a separate instance, wouldn’t multiple cores ostensibly allow the synth and drums to be processed in parallel without overloading either core?
The original thread was unclear on this. It focused upon whether a single rackspace could be processed across two cores (and the answer was more or less: the alarming complexity of code would not be worth the meager gains.)
However it did not really discuss multiple instances at length. Can someone verify that multiple instances run in separate processes and are therefore available for processing on separate cores? Further to that, can anyone verify whether Windows OS actually does a good job of using separate cores for separate instances when GP is used?
I didn’t think it worked that way. I thought the processor did its best to meet the global audio buffer setting, and played back the result precisely that many samples later. If the processor failed to complete its processing tasks, the audio will have crackles and pops as the frames are missed.
Even if I’m wrong and the latency is dynamic with the processor load, it would only be an issue when the difference is greater than 10ms, provided the two audio streams aren’t carrying the same information. I can hear a 12ms delay during performance, but it disappears below that.
Quite different if the same audio is processed in parallel and is played back together with its ‘twin.’ Then you get comb filtering (if the delay is static) or chorusing (if the delay is drifting dynamically.)
TLDR: In my setup I would be fine with a <10ms latency difference between instances (although I don’t think that would be the result.)
So, my source for these assumptions was your own post’s ‘list of assumptions:’
Assumption 2: Gig Performer launches all plugins in the same thread
All the blocks in connection view (= plugins) are launched in the same thread by GP. As a single thread cannot be run on multiple cores at once, you get a CPU-intensive thread which cannot use more than a single core.
…but perhaps in the above you meant “by a GP instance?”
and here:
So that means, plugins like Kontakt can easily distribute their loads over multiple cores and do not stress the “main GP audio thread” very much, whereas in Omnisphere, whether you’re using multiple sounds in a single instance or multiple instances with one sound each, they all run in a single thread.
…but perhaps the instances you mention here are instances of Omnisphere within a single GP instance, and not separate instances of GP?
I don’t think these assumptions were ever challenged or invalidated in the original post… or did I miss this?
I can verify that on my system, multiple instances of GP will run under separate process ID’s, and thus operate threads independently of each other. Those PIDs will generally run on separate cores. I say “generally” because I do not believe GP can control that. I believe it’s up to windows, and if windows feels like sticking them on the same core I suppose it can, although that seems unlikely if the system is otherwise unencumbered.
Excellent. A thousand thanks for doing my homework for me.
Unfortunately, I’m now led back to my original question. In my unique case, where separate GP instances will be processing separate audio streams, and where these streams will not intersect until the digital output, will I benefit enough from a gigantically-multicored CPU to merit using an AMD over an Intel?
…and it looks like you’ve answered my question in another reply while I’ve been typing. Thanks!
Awesome. Score one for the AMD Ryzen line.
(As a note, this purpose-built PC will only have the bare bones necessities running. It is basically an embedded device with an as-needed screen for config and troubleshooting.)
That’s my understanding as well. More reason to remove all unnecessary software and allow the OS to make obvious choices about process/core allocations.
And once again, it seems my unique use-case would benefit more from an AMD Ryzen than an i9…
).
Sorry for the ambiguous formulation.