How many CPU cores do I need to run Virtual Instruments in a Digital Audio Workstation?

hey folks Richard Ames here coming to you today from coronavirus lockdown where I've recently gotten a haircut from someone who doesn't do haircuts so don't judge what I'd like to talk to you about today is how number of CPU cores affects your ability to run virtual instruments within your digital audio workstation now there number of good references out there on the web using da bench and some other reference projects to look at which CPU is better and how many CPU cores relate to how many plugins can you use within a project and that's all good information but that's not what I'm looking at in this particular video what I'd like to answer in this video is how many CPU cores are good enough to run a collection of pretty typical projects and so what I've done is I've put together a collection of three projects that span a decent range of the types of things you'd run within a digital audio workstation particularly with regard to how you use virtual instruments and then I've measured their performance in terms of how many dropouts do you get when you play them back and I've measured that in terms of both the buffer size that you use during playback and then the number of CPU cores that are active so what I've got at the end is an indication of of from a practical standpoint what number of cores do you really need in order to write and produce music using virtual instruments within a digital audio workstation my setup is built around Cubase 10 Pro and a fireface connected via USB this is a fireface 802 I do use multi processing within Cubase I do not use a zo guard though because I've had some issues with that in the past particularly with Vienna Ensemble Pro I do boost the audio priority I have the Steinberg audio power scheme activated basically what that does is it ensures that the processor speed is always running at its maximum of four point four gigahertz and within the BIOS that is set up to be constant across all the cores so there aren't certain cores that are higher certain courses that are lower it's set up so they all run at that same speed and then within the fireface settings dialog this is how I change the buffer size so what I'm looking at within this video is from a maximum of 256 down to a minimum of 48 samples and then the processor that I have in this machine is an i-9 10 940 X that's a 14 core processor with hyper threading so you can see all 28 cores available here the way I create different numbers of cores is by going into the BIOS and disabling the cores I don't need so I have a maximum of 14 available if I want to test 10 I simply go into the BIOS and disable for a few more quick comments about the setup first of all I'm running Windows 10 completely stocked so there are no tweaks or modifications to the operating system second I'm running one buffer for the Vienna Ensemble pro connection so for the project that uses two slave machines over Ethernet there is additional latency there in the form of one additional buffer that goes out to each of the slave machines for the Ethernet connection and then third because the slave machines are present in the first reference project they are certainly a bottleneck and could have a significant impact on the total system performance so so while a measuring effective number of CPU cores and buffer size certainly the main DAW has an effect there but also the slaves for those projects have a significant impact as well and we get around that in the second and third projects where there are no slave machines so what I've put together I think is a collection of projects that will represent a broad spectrum of different types of scenarios for different use cases another important consideration regarding the setup described here is that it is on PC it's not on Mac it is within Cubase it's not within Ableton or some other DAW it is using an rme fireface 800 - so the results that I present later in this video could be very specific to this setup but I don't think so because I've seen the same basic trends on both Mac and PC I've seen the same basic trans in both Cubase and Ableton and I run Ableton Live as well and I've seen the same basic trends pretty much independent of type of audio interface so it is a consideration the results might be specific to what I've described here so if you've got some indication that that's the case I'd be curious to hear about it so drop a comment in the notes below and let me know the first track I'm using for these tests is a typical hybrid orchestral track with a full string section so there's violin one violin two viola cello double bass some woodwinds piccolo couple of flutes clarinet bass clarinet bassoon a full brass section trumpets horns trombones tuba harp piano xylophone standard orchestral percussion snare drum timpani etc and then some of the larger epic percussion you tend to hear in these types of tracks now what you see right here are only the tracks that are used this is within my standard orchestral template that has a total of 477 tracks of which 347 are MIDI then there are a bunch of VST instrument tracks that are audio outputs some effects channels for reverbs and then the group tracks this is what I use to make my stems are these group tracks right here so there's also some synth and effects tracks up here at the top I have three synth tracks and a couple of sound effects throughout the track and then what I've also done for this test is for each of the sections I've taken the lines so for example these string lines here and I've duplicated them across multiple libraries all playing at the same time to really put a significant stress on the system so for example this strings section here the east-west strings all of these lines are doubled in the VSL strings and the LA scoring strings and the spitfyre strings the woodwind parts are duplicated in both east-west woodwinds and VSL woodwinds and all of the brass parts are duplicated in east/west brass cinah brass and VSL brass now most of the percussion is run locally here on a local vienna ensemble Pro server but most of the instruments are run on to slave machines so all of the east-west libraries are run on this i7 6800 k that's overclocked to 4 gigahertz and runs constant at that speed so it does not down clock when the CPU usage goes down and then a bunch of the other libraries are run on this AI 970 900 X that is overclocked to 4.2 gigahertz now both of these slave machines are connected to my master DAW via Vienna ensemble Pro over a Gigabit Ethernet connection the second track I'm using for these tests is more of a pop or EDM type of style so there are seven synthesizer tracks in this project there are six instances of serum one instance of omnisphere there's a MIDI track here running to contact with piano in it there's another MIDI track here with a drum sampler and then there's a bunch of audio tracks so there are a couple of live guitar tracks here that are ported into a group channel track there is a strings audio track that was bounced down there is some percussion here in an audio track and then for vocal tracks and three effects tracks that are also audio so the total track count for this project comes out to 31 that includes another group channel track that I use to duck everything behind the kick drum and if you look at the tracks there is a pretty standard collection of plugins here so compressors delays saturator errs reverb there is guitar amp simulator here what's maybe a little different is on the output bus I've got this ozone mastering plug-in here that includes a Maximizer dynamics exciter and equalizer and if I bring up the azio meter here you'll see when I turn this on it gives a pretty good kick to the the real-time performance of the system so that's good because it'll help us understand how the number of processor cores effects a project where there is clearly a pretty significant time limitation the third project I'm using for these tests is exactly the same as the first with the exception that all of the instruments are running on the same computer I'm still using the exact same number of duplicate libraries across the string lines the woodland lines and the brass lines the difference is they're now all streaming from one computer and they're all connected via one instance of Vienna ensemble Pro that is running on the same machine as the doll the way I counted the number of audio dropouts was I loaded up the real-time performance meter in Cubase along with a handy little mouse click counter app and what happens is every time you get an audio drop out even if you can't hear it the indicator turns red in the as geometer so that tells you that the dog couldn't keep up with the audio stream that's going out to the sound card and to your speakers and so it turns red and what you can do is you can click on it so it clears it out and goes back to its normal state and then the next time dropout occurs it turns red again so what happens is you play through the track and you click on that indicator to clear it out each time and the mouse click counter keeps track of how many times you've done that so I do that three times through the track and at the end I have an indication of the total number of dropouts after those three times through the track and I can calculate an average number of dropouts per minute of playback here are the measurements for the hybrid orchestral project in the master and slave configuration and let me take a second to explain what you're looking at on these plots so along the horizontal axis here are the buffer sizes that I tested 48 64 96 128 and 256 and for each of those buffer sizes there are six vertical bars here and those vertical bars represent the average number of dropouts per minute for the different number of cores that I tested so four six eight ten twelve and fourteen and what I did on these plots is I capped them at thirty dropouts per minute because if you're getting more than thirty dropouts per minute you're not going to run the project at that buffer size anyway it's it's an unworkable number of dropouts in fact even two or three dropouts a minute depending on how severe they are can be unworkable as well so I capped the plot at 30 the truth is for the 48 buffer size there were many hundreds of dropouts per minute but whether it's 30 or 200 doesn't make a difference you're not going to run the project at that buffer size for 64 they did come down into the range of around 10 to maybe 20 and there was definitely a dependence on number of cores so as the number of cores increased in general the number of dropouts did decrease however the dropouts were still severe enough that you're still not going to run the project at the 64 buffer size so the difference between four cores and 12 cores of 14 cores actually doesn't matter because even at twelve or fourteen cores it's still not good enough to make it a workable project by the time you got to a 96 buffer size however the number of dropouts did drop down to a manageable level they're still obvious there's still a little bit difficult to work with but in a pinch you could certainly make it work and then at the 128 and 256 buffer sizes absolutely no issues working with those two buffer sizes even all the way down to four cores so once you got up to a buffer size of 128 or 256 whether you were running four cores or 14 cores didn't make any difference the project ran just fine regardless of that core count for the pop I am track the results look significantly different so at both the 48 and sixty-four buffer sizes the number of dropouts per minute were so large that you wouldn't run the project at that setting by the time you got to 96 this situation did improve a little bit and in fact at the four six or eight core count the project was pretty much unusable but you could kind of get by with it at twelve or fourteen still certainly less than ideal but again in a pinch you could probably make it work at those higher core counts at the 96 buffer size but at the 128 or 256 buffer size again no issues whatsoever whether you're running four cores or 14 cores the hybrid orchestral track run from a single machine is definitely the most stressing of the three projects tested here and that's reflected in these measurements at 48 64 or 96 buffer size the number of dropouts totals in the many hundreds per minute and you'd never run the project at any of those buffer sizes regardless of number of cores so four cores versus 14 cores didn't make any difference now when you got to 128 things got interesting because there was some indication of a practical advantage to higher core counts at the four and six core measurements you see many hundreds of dropouts per minute but by the time you got to eight there was a significant decrease so you came out of the range of absolutely unusable and into the range where okay maybe things are starting to be workable and then the advantage from eight to ten is a little bit but from 10 to 12 to 14 there's essentially no difference and even from 8 to 10 the difference is measurable but from a practical standpoint you're still getting a decent number of dropouts you'd still notice them there's some chance it could impact your workflow so the reality is that you'd just bump the buffer size up to 256 anyway at which point there's really no advantage to anything more than six cores okay so those are all the measurements and they're important because they help you to quantify what's better but as I said at the beginning of this video what I'm really interested in determining is what is good enough and the way I'm making that determination is by evaluating what I can actually perceive so while the Accio indicator might show a missed buffer transfer quite often that miss is so small that you can't hear it and that's what the information on this chart reflects so I've categorized each of the tests in terms of whether or not the dropouts were perceptible and more to the point perceptible enough to be a hindrance to your workflow so for example for the hybrid or Kestrel with a master plus slave set up at 48 and 64 buffer sizes absolutely the dropouts were perceptible they were constant they were a major hindrance to getting anything done so you would never run at those buffer sizes contrary to that at 128 and 256 buffer sizes the dropouts definitely were not perceptible so yes they occurred maybe once a minute once every two minutes but they were not significant enough to have any kind of impact on my workflow now the story changed a bit at the 96 buffer size where there definitely were some perceptible dropouts but in general they weren't significant enough to alter my workflow so you could keep working through it it certainly wasn't ideal they might get a little annoying after a while but if you're under a deadline you're in a pinch you got to get something done you could certainly make it work so that's what's indicated by the some label in these tables here for the pop ETM track the story is very much the same we're at 96 buffer there were some perceptible dropouts that might cause a hindrance to your workflow 128 256 both perfectly fine no issues and 64 and 48 absolutely no way you'd run that project at either of those buffer sizes and then for the hybrid orchestral setup on a single machine the results were different there because the the unworkable range extended all the way into the 96 buffer size and part of the 128 buffer size and again this is where we did see that some practical advantage exists for a number of cores as you move from six cores to eight cores at the 128 buffer size on this project you went from absolutely unworkable to yes maybe I could make it work but again the truth is you'd probably just bump the buffer size up to 256 at which point the distinction between four cores and fourteen cores disappears and that I think is the key takeaway from these tests it's pretty hard for me to say there's a practical difference between 6 or 8 cores and 14 cores yes I did see a bit of a practical advantage going from 6 cores to 8 cores when I tried to run all of that massive project from one machine but again you could just bump the buffer size up to 256 which is still a perfectly workable buffer size and the latency associated with a buffer of 256 is still much lower than the latencies you get with acoustic instruments that people have been playing for millennia so again from a practical standpoint I think six or eight cores is about all you need to run a collection of virtual instruments within a digital audio workstation hopefully you've gotten some useful information out of this video I've wanted to do this kind of test for a while now because as I've gone through the last several cycles of CPU upgrades going from four cores to six cores to ten cores to 14 cores I really haven't seen much of a difference in terms of my overall workflow I still run at the same basic minimum latency I still experience the same basic number of dropouts for a given project type so I really wasn't seeing any difference as I increased my core count and I think those results are borne out within the tests that I've shown here in this video so again I'll throw in the caveat that perhaps it is specific to Windows I'd be curious to know if anyone else has a different experience on Mac perhaps it is specific to Cubase maybe if you run in Ableton or some other DAW the number of cores is more of a factor but certainly from my perspective for the types of projects that I've shown within this video and for the setup that I'm running I really haven't seen much of an advantage for a number of cores so if you're shopping for a new CPU for a digital audio workstation make sure you keep that in mind

Channel: Richard Ames Music

Views: 39,958

Keywords:

Id: PmCEyLg5bpU

Length: 19min 42sec (1182 seconds)

Published: Wed Apr 22 2020