CPU Performance vs. Real-Time Performance in Digital Audio Workstations (DAW)

hey folks Richard Ames here again with another video on digital audio workstation performance and today I'm going to be discussing one of the most misunderstood elements of DA performance and that's the difference between real-time performance and CPU performance I've encountered countless numbers of folks who say something along the lines of I just got this dual xeon beast machine with 16 cores per processor and it's off the charts on the cpu benchmarks but my buddies measly 4 core i7 can run more virtual instruments at lower latency and with more plugins across the entire project how can that possibly be well the answer lies in the difference between real-time performance and CPU performance rest assured that that dual xeon beast machine does indeed have significantly more cpu power than that four core i7 however for DA use it's almost always the case that the real-time performance dictates the overall system performance so if that dual xeon beast machine has poor real-time performance no amount of cpu power is going to make it function well as a digital audio workstation so what precisely is the difference between real-time performance and cpu performance let's start to answer that question with something that every da user does on a regular basis exporting audio here's a typical track that uses full orchestra through ve Pro over Ethernet it's got a few synths a full string section some woodwinds full brass section bunch of percussion and this track will play just fine at a buffer setting of 128 samples there you go I'm using a fire face with the buffer size of 128 samples it'll play just fine with that buffer setting over the entire length of the track so I'll start to play back here and you can hear that indeed no audio artifacts no pops no crackles it's chugging along just fine no issues down here in the VST performance meter now let me go ahead and rename this limiter there you hear the crackles so this limiter is pushing the computer beyond its capability to handle the audio for playback but here's the first hint that the CPU is not the limiting factor if you look down here at the windows performance meter I'm really never getting much above 50 percent or so so that's telling me that my CPU is mostly just sitting around doing nothing so it sure seems like an unlikely cause of the crackles so here's an even better way to show that the CPU is not the limiting factor let's stop the playback for a second and what I'm going to do is an audio export so I'll pull up the export dialog box I'll save it to some bogus file name and what I'll also do is when the export starts is I'll start the stopwatch down here and we'll see how long this takes so let's start the export yep I've done it once before so let me overwrite that and once it gets going we'll go ahead and start the timer here now what I'll do at this point is all pause the video and then bring you back in when the export process is done okay this three minute and 33 seconds took about two minutes and 48 seconds to export now keep in mind that while I was doing this export I had the screen capture and a separate audio capture process running in the background so the computer is working a lot harder than it normally would have to and without these extra burdens it actually takes about 2 minutes and 27 seconds to export this 3 minute and 33 seconds now let's think about this for a second the computer can't keep up with the audio over the course of a three and a half minute track when playing it back however it can process all of the exact same audio and write it to disk in significantly less than three and a half minutes how can that be if the CPU is sufficiently powerful to do all of the audio processing in much less than three and a half minutes then if you give it three and a half minutes it's got more time so playing it back should be a much easier task right well no the reason is that playback is a real-time process and writing to disk is a non real-time process and there are two very different elements of computer performance if I were to double or triple my CPU power in this example I might write to disk more quickly but clearly I'm not going to impact the real-time playback because my CPU is already more than sufficiently powerful to process all of the data much faster than is required for the playback so if you're able to export audio faster than real-time you're probably not CPU limited you have plenty of processing power available to do all of the audio processing much faster than is required in real time but you can't do it in real time let's dig a bit deeper to understand why that is the CPU has a number of devices for which it must provide processing power in this example I'm showing a hard disk monitor hooked up via video card and some USB devices and of course in reality the CPU has many more devices and processes that it has to deal with but let's use these three as an example when one of these devices needs the CPU it interrupts the processor with a request for processing and while the CPU responds to this request for processing it is locked up by the device to which it is responding sometimes even if the computer has provided all the necessary processing for the device some devices continue to lock up the CPU so that it's not able to respond to other processing requests this is why your CPU is rarely anywhere near 100% usage it spends a lot of time waiting for something else to happen now the lock-up problem has little to do with CPU power it's determined almost entirely by the device causing the lock-up but it does determine the overall responsiveness of the system that's the essence of the difference between real-time performance and CPU performance you can have an infinitely powerful CPU but if it's locked up by some device then it can't respond to other devices and the system will perform poorly even though there's plenty of CPU power available okay so real-time performance and CPU performance are affected by different elements of the system and they affect the overall system performance in different ways why is it that real-time performance is so much more important for digital audio workstation use than say video editing or working on a spreadsheet those activities use the same system but they don't seem to have any issues with real-time performance why not the answer is in the difference in the response times required for those different activities unlike a video editor or spreadsheet or web browser a digital audio workstation has to continually process data in near real-time because it's taking inputs from external MIDI and audio devices and processing them on the way back out to the monitors often while also playing back audio that was previously recorded if you hit the keys on your MIDI keyboard and it takes a hundred milliseconds for the sound to come out of the monitors that's very disconcerting and you're going to record a bad take in a video editor or spreadsheet however the user input and resulting actions are often separated by hundreds or even thousands of milliseconds with no impact on workflow in fact in a video editor the user input is almost always entirely separate from the playback you make some tweaks then you view the playback then you make some more tweaks then you view the playback and if there's a delay of a couple hundred milliseconds from the time you finish the tweaks to the time you start the playback you'll never notice it those same couple hundred milliseconds in a doll however are very noticeable and not only does it have to react faster than that couple of hundred milliseconds it has to do so while also playing back the data that you've already recorded in order to understand how this responsiveness is related to real-time performance let's take a look at how audio gets from the DAW to your monitors your audio converter must continually provide output to your monitors so it requires a continuous stream of digital audio data from the DA this audio is transferred in chunks of data at a time the size of this chunk is called the audio buffer size and is set in your audio interface parameters this buffer size is related to the responsiveness of the system because once the audio is moved into the buffer it takes time to do the conversion so there's a continual cycle of moving audio into the buffer and then waiting for the converter to produce the analog signal that is sent out to the monitors while that conversion occurs the next buffer must be filled that cycle repeats over and over as the converter receives digital audio and converts it to the analog signal that goes to the monitors because the dawn needs to respond quickly this buffer must be very tiny and therefore refilled very often because the DA can fill only one buffer at a time the smaller the buffer size the more response of the system however the smaller the buffer the more efficient the other elements of the system must be in order to ensure that the CPU isn't locked up for too long that's why dot performance is much more affected by real-time performance than most other applications the buffers for DA use drive the system to extremely quick response times much faster than those required for most other processing tasks let's bring back our other devices and see how they affect the audio buffer transfers when the devices in the system have good real-time perform there are no lock ups that prevent the cpu from processing the audio data and filling the buffer at the required interval so the processor is able to attend to the processing requirements for all elements of the system and keep the audio buffer filled so that there's a constant stream of audio data going to the audio converter when a problem device locks up the CPU however the CPU can't fill the audio buffer and the audio data stream has a gap in it or worse a garbled mass of random data of course the audio converter doesn't know what's in the buffer so it dutifully converts the garbage digital data into garbage analog data that produces garbage sound from your monitors those are the Pops clicks and crackles that you hear sometimes though the computer just puts everything on pause until the buffer is filled in that case you hear and see a stutter either way there's a break in the audio stream that you hear because the buffer wasn't filled in time as we already demonstrated the CPU is more than powerful enough to do all the audio processing faster than is required for real-time playback the break in the audio stream is not because the CPU can't keep up it's because it's locked up by some other device so even if we were to put in a more powerful processor we likely wouldn't see any reduction in the number of audio crackles because the CPU is not the bottleneck now I say likely because it is possible that the CPU is not powerful enough to deal with the processing requirements of one of the devices but as of about five to seven years ago that almost never happens it's the device itself that causes the lock-up not the lack of CPU power so what about the guy who upgrades his computer to one with a more powerful CPU and sees his audio problems go away well if the only element he changed was the CPU then in fact yes he probably was having CPU problems but that's almost never the case most folks when they get a new CPU they also get at least a new motherboard and more likely an entirely new computer well if you replace either one of those components then you've got new links to the disk system new links to the USB system new links to the video system new links to all of these other systems that are potential sources of real-time performance problems so you can't say it was the CPU upgrade that improved the performance furthermore lots of folks upgrade to a new computer with a more powerful processor and get worse dull performance if the new system has worse real time performance than the old system then it doesn't matter if the CPU is more powerful it's not going to perform well as a digital audio workstation so buyer beware CPU benchmarks don't tell the whole story for doll performance you need to find somebody who's running the types of projects that you run the right number of track counts the same types of virtual instruments the same types of plugins at the same types of latencies only with those types of examples will you know for sure exactly how that new system is going to perform when you use it now let's take a look at a non real-time process like the audio export example and compare it to a real time process there are two fundamental differences between real-time playback and non real-time export first in the non real-time export there is no continuous audio stream so the data can be written to disk as they become available not according to a precisely timed interval as required by an audio interface that allows the processor to work in the audio processing among all the other tasks it has to do there's never a situation where it's going to miss a buffer transfer because unlike the real-time process the CPU has control of when the buffer transfer occurs second the processor can provide however much data at once in each chunk so if you have a very powerful processor that can crunch a lot of data in a short period of time then it will write to the disk a lot faster than a processor that is less powerful in the real time scenario the processor can only provide a single buffers worth of data for any given buffer period it can't store them up for future buffer transfers that's one of the major reasons why powerful processors are a big help for video rendering but not so much help for DA use here's an example of video rendering as you can see the CPU usage is extremely high nearly a hundred percent most of the time compare that to the real play back example at the start of this video where the CPU usage rarely rose above 50% even though we were getting crackles in the audio in the real-time audio example the CPU can provide no more than one buffer of data at a time and it must do so at a precisely defined interval so even if the CPU is not encumbered by other devices it can't use its processing power to fill more buffers so it spends a lot of time just sitting around for the non real-time video export however the CPU can fill as many buffers as it wants whenever it gets the chance so the CPU spends a lot less time waiting for something else to happen as a result the average CPU usage is much higher and the rendering performance is a strong function of the CPU performance now let's compare the real-time and non real-time processes to see how they differ well look at both and count the number of buffers each one transfers as time progresses again the real-time process must provide precisely one buffer of data at precisely the right interval if it gets locked up by some other process it can't catch up by crunching more data in the next time interval that audio train has already left the station the non real-time transfer on the other hand can provide however much data at once at whatever interval at once so even though there are periods of time where it falls behind it can catch up by crunching a lot more data at a later time so on average over timescales of seconds or longer the non real-time process can crunch a lot more audio data than the real-time process that's why the audio export takes less time than it takes to play back the entire track there's plenty of CPU power there to crunch all of the audio data faster than is required for that real-time playback rate however if the CPU can't guarantee that it will provide each chunk of data at exactly the right time then you'll hear pops and crackles and stutters even though on average there's significantly more CPU power there than you need that's also why increasing the audio buffer size helps solve a lot of audio problems you're essentially increasing the window of opportunity that the CPU has to fill that audio buffer that gives it more time to deal with potential lock ups from other devices within the system so for da use it's the responsiveness or real-time performance that is the dominant factor in the overall system performance again you can have an infinitely powerful CPU but if it's locked into some misbehaving device or process it can't break free to fill that audio buffer exactly when it's needed and you'll hear pops crackles and stutters in your audio as a final example I'll show you a problem on my laptop that also clearly demonstrates a situation where the CPU is plenty powerful but the real-time performance of the system is inhibiting audio performance so here's a simple project running on my laptop I've got a couple of the Cubase synths I've got retrologue on this first track right here and then Spektor on the second track and these synths are just running up and down the chromatic scale in sixteenth notes at 120 bpm so the purpose of these tracks is just to produce a lot of notes and to give something the computer to playback so let me go ahead and start the playback let me show you first of all so I've got this running through a Steinberg u r1 to audio interface set to a buffer of 128 samples it's connected via USB - so pretty standard set up and down here on the bottom left you see the DPC latency checker and it's showing Green across the board here you'll notice these DPC latencies are a little bit higher than what you'll get on a typical desktop but that's common a laptop generally will have a higher overall DPC latency a higher system latency than an equivalent desktop computer and this is an i7 processor by the way so let me go ahead and start the playback and you hear those synths running up and down those chromatic scales and the computer handles this just fine so you see here in the VST performance meter no red overload indicators CPU usage is relatively low 10% 12% something like that so clearly this laptop is more than sufficient to handle playback on this project now here's the exact same laptop with the exact same project loaded up but booted from a different Drive in the previous segment I booted from the SATA SSD internal to the laptop this time I'm booting from the PCIe SSD so a different drive it's got a different connection to the processor and different real-time characteristics and the first thing you notice are all of these red bars down here in the DPC latency check red means bad right yes definitely means bad in this case and you can see the maximum Layton sees or 12,000 microseconds which is 12 milliseconds which is very high for a system latency however if you look at the CPU usage after I start playback here it's about the same 10 percent 12 percent something like that but you can see all of the VST performance spikes and I'm not sure if you can hear the crackles in the audio because they're very subtle but they are there and certainly this particular playback is not functioning nearly as well as it was when I booted from the SATA SSD drive even though this is exactly the same computer with exactly the same hardware running exactly the same project again it's the exact same laptop with the exact same CPU running the exact same project so how can there be such a dramatic difference in the performance of the system well the answer is that the PCIe drive is one of those misbehaving devices that locks up the CPU and prevents it from delivering the data to the buffer when required so there are a lot of missed buffers and a lot of garbage that gets sent out to the sound card so it doesn't matter how powerful the CPU is it's not being given the opportunity to fill the buffers at the required intervals and the system performs poorly so let's say you are getting crackles pops and stutters you now have some understanding of what might be causing them so what can you do about it the first thing to do is check to make sure that your audio buffer size is not extremely small and that your sampling rate is not extremely high most audio interfaces default to buffer sizes and sampling rates that will run fine when the interface is connected straight out of the box maybe a buffer size of 512 and a sampling rate of 44.1 killers those are pretty standard however I found that 256 or lower gives a more natural feel when using virtual instruments below that I can't tell a difference but there are folks who like to run at even smaller buffers so season to taste however if you're able to run a 200 track virtual orchestra with several synths dozens of EQs and a few reverbs at a buffer size of 128 and a sampling rate of 44 point 1 kilohertz then I'd say your system is performing about as well as anything out there if you're working primarily with audio and have only a few virtual instruments then you should be able to run at buffers of maybe 64 or possibly even smaller now these buffer settings are assuming you're running at 44.1 or maybe 48 kilohertz if you're one of those folks running at 96 kilohertz or even higher your buffer settings are going to be higher most of the other composers I know run at 40 4.1 or 48 kilohertz with buffers between 128 and 256 fewer at 64 and 512 and fewer still outside of that range if you set your buffer to 256 or maybe 512 and you're still encountering some problems there are a few common culprits to investigate these include video cards audio interfaces network interfaces especially wireless interfaces USB controllers and disk controllers these devices are in my experience the most common causes of DAW performance problems not CPU in fact I'd say that audio cards and video cards represent more than half of the dot performance problems that I've encountered so a logical jumping-off point for your debugging process is to make sure you've got all of the latest drivers installed for all of these devices find them download them make sure you've got the most recent ones that are compatible with your system and hopefully one of those will fix the problem if the problems don't go away try disabling devices until you find the one that's causing the problems we're getting a bit PC specific here so apologies to the Mac users but a good way to figure out which device is causing problems is to disable devices and load up a latency checker like DP see latency checker or latency Mon these tools are both free but note that DP c latency checker doesn't work on Windows 8 and presumably Windows 10 these tools are handy because they take the da software out of the picture and allow you to evaluate the performance of your hardware alone if you load up these tools and they say you have no problems as DP C latency checker is showing here then the issue might be with your DAW software a virtual instrument or a plugin if that's the case then make sure you have the latest patches for your DAW software and if possible try a different dog to see if you're having the same problem if the latency tools do show a problem then I recommend disabling devices one at a time rebooting then reloading the latency checker to see if the problem went away if it did you know which device caused the problem and you can replace it of course this approach doesn't work with the video card so you have no recourse there other than to simply replace the video card but don't forget about trying the drivers especially with video cards I found that dot performance can be very sensitive to the particular driver you're using for your video card and it's not always the case that the most recent driver is the best one sometimes you have to go back a couple of versions to find a driver that works well with your system if none of these approaches works then you need to dig even deeper the next thing to try is a BIOS update the BIOS is the basic input/output system in your computer and it handles all of the very low-level communications among all of the devices in your system so it can have a significant impact on real-time performance the manner in which you do a BIOS update is very system dependent but it's pretty easy to find information on how to do it on the web so just look up someone who's got a computer similar to yours find out how they did the BIOS update better yet check with the seller of your computer or check in the man there's usually good information on there on how to do a BIOS update if the BIOS update doesn't work there's probably not much else that you can do and the laptop example that I showed you there's nothing that I can do to make that laptop perform well when booting from the PCIe drive there's something about the hardware or the driver or something in there that's preventing the system from having good real-time performance hopefully Intel or SanDisk or HP will come up with a patch that addresses that issue and fixes my problem wish me luck in getting one of them to claim responsibility in the meantime I'm just going to have to boot from the SSD on that computer and there are systems like that some systems just can't be made to perform well from a real-time standpoint if that's the case the only recourse you have is to either deal with it or find another system that does have good real-time performance the good news is you've seen this video and you know that CPU benchmarks are not the best way to determine Doll performance so you'll be a much more informed buyer finally it's important to note that you might have the world's best performing hardware and still run into troubles within your DAW the truth is that some virtual instruments and plugins are just poorly written and the world's best performing hardware will perform poorly if coupled with poorly written software the good news is that even the worst performing instruments and plugins that I've encountered are still perfectly workable so long as the system has decent real-time performance they might be annoying but they're not going to be a bottleneck in your creative process hopefully this video has given you some insight into the difference between real-time performance and CPU performance and more importantly how that relates to digital audio workstation performance as I said in the intro this distinction is probably the most misunderstood aspect of dot performance so if you're about to get rid of your old machine see if you can apply some of the knowledge you've gained in this video to squeeze a bit more life out of it if it's not possible to get the performance you require out of your current machine at least you've got some information that you can use when looking at a new machine remember CPU benchmarks don't tell anywhere near the whole story when it comes to digital audio workstation performance so good luck in your musical endeavors and remember to check back here for more of my videos on digital audio workstation performance you

Channel: Richard Ames Music

Views: 175,538

Keywords: Digital Audio Workstation, Digital Audio (Consumer Product), music, technology, film, film music, television, television music, composer, computer performance, CPU benchmarks, Central Processing Unit (Computer Peripheral)

Id: GUsLLEkswzE

Length: 28min 8sec (1688 seconds)

Published: Tue Jul 21 2015

Reddit Comments

[u/nerd866]

Very, very enlightening! I wish he mentioned more current-gen hardware that has been proven to have good realtime performance (GPUs + driver versions, audio hardware + drivers, external hard drives, mice, keyboards, MIDI keyboards, printers, motherboards, BIOS versions, etc.). It seems finding the specific HW/SW that gives optimal performance is the most challenging piece of this puzzle.

Other than that, great overview of the issue! The DPC latency checker is a handy tool! Apparently I'm staying between 40 and 179us so I'm happy.

[u/petermidi]

apparently one of the most interesting videos regarding DAW-performance in the net!