What's new

[VIDEO] CPU Performance vs. Real-Time Performance in Your DAW

Markus Kohlprath

Active Member
This is a great video - there should be a thread where videos like this can be collected. Thanks for taking the time to do this Richard!
This is a great idea! And also where we could share and compare our computer specs and collect it in an easy to find and focused way. Since I'm concerned with that subject it's like a discovery journey through a dangerous jungle with threats around every next corner respectivly updates, new hardware and on without almost no guidance from so called "computer specialists" outside the audio world. And those whose life really depend on the subject and started long before I did often use the oldest gear and programm versions without updating as long as they can. At least in my area.
So a bit of structure in our do it yourself- helping each other way of dealing with it would be great!
 
OP
rgames

rgames

Collapsing the Wavefunction
Glad you guys found some useful info. I'm working up another one using a laptop for a full orchestral template - hopefully it won't be another 18 months before I get that one done...

Re: why the DPCLatencyChecker won't run in Windows 8 - when Microsoft went to Win8 they made a lot of under-the-hood changes to interrupt handling so that the OS would more easily port across desktop and mobile devices (so I am told). The DPCLatencyChecker tool wasn't updated to adapt to those changes.

However, LatencyMon does run in Windows 8 so you can use that. It's a little more confusing, though, because it provides a lot of other data that I haven't seen related to DAW performance. The LatencyMon page faults and ISR measurements are regularly way in the red on my system but my DAW runs just fine. It's only the DPC measurement that I've seen make a difference in DAW performance. So keep that in mind. That's the nice thing about DPCLatencyChecker - it gives you only the info you need to figure out whether or not you have any latency problems that relate directly to DAW performance.

One other point about DPCLatencyChecker: I use it only as a threshold tool. So long as the latencies are down below 200 us or so then your system is performing about as well as anything I've seen (from a practical standpoint). In other words, trying to minimize DPC latency below that level probably won't provide any practical benefit. There are supposedly some magic tweaks you can do to get the DPC latency way down 10 us or even lower but they don't seem to have any practical benefit (unless your goal is to run benchmarks...!). If you have spikes in the 1000 - 10000 us range, though, getting them down to the 200 us level will probably provide better performance. Returns diminish very quickly below that.

And yes, finding DAW-specific benchmarks is really tough. The PC enthusiast sites like AnandTech and Tom's Hardware have started including DPC Latency measurements as part of their benchmarks, though, so that's a step in the right direction. The issues we face with real-time performance don't affect 90% of computer users, though, so there's not a lot of demand for this kind of performance benchmarking.
 

Living Fossil

Senior Member
Thanks for this video.
What i'm still looking for, is a chart that lists the performance of different CPUs exactly for the mentioned task: for audio realtime performance (e.g. i'm wondering if a 8core CPU @ 3.0 GHz is performing better than a 6core @ 3.5 GHz)...
 
OP
rgames

rgames

Collapsing the Wavefunction
Yes - that's hard info to come by. Part of the reason is that it's so dependent on what you want to do. If you're working with only a few synths and some audio then pretty much any machine will do. But if you're running a full orchestral template then it gets a lot trickier.

Here's what I know from experience: my i5 2500k (4 cores / 4 threads), i7 920 (4 cores / 8 threads) and i7 4930k (6 cores / 12 threads) all provide basically the same number of streaming voices. The 2500k and 4930k were both clocked up to 4.4 GHz and the 920 was around 3.8 GHz or something like that. So for the sample streaming application, there's basically no difference (I used VSL, LASS, Cinebrass and EWQL brass to do the benchmarks).

I've heard some folks say that they run a lot of synths and are CPU limited but I've never run in to that problem. And like I said in the video, if they can export faster than real-time then they're probably not CPU limited. A lot of folks confuse the ASIO meter with the CPU meter - they're not the same. And even within Kontakt and VSL, the bar labeled "CPU" is not, as far as I can tell, actually measuring CPU performance. So that causes a lot of confusion.

The conventional wisdom is that clock speed matters more than number of cores and I have seen some hints that's the case. One thing I know for sure is that I've seen a number of dual-Xeon systems don't match up to the mid-level i7's for DAW use. They're clocked lower but they're also on a completely different motherboard. So which is the cause of the reduction in performance? There's no real way to say for certain.

The good news is that pretty much any mid-level i7 will provide good DAW performance if the system has good real-time performance. You don't need to tweak any OS parameters to make it work, either. I run everything stock - there's no "magic dust."

rgames
 

PMortise

Active Member
Bravo, Richard! Many thanks for this.

So, in regards to video cards it's just a matter of seeing what "fits" through trial and error? What about the connections used per monitor: DVI vs HDMI, etc?
 
Last edited:

Hannes_F

Traveller in boundlessness, at home in the Now
Here is one thought for PC users, inspired through this video: Windows will install a buffer swap file for your RAM content on your harddisk (official name "pagefile"). Now if you are using several hard disks (which is mostly the case here) then this buffer file can be distributed over your harddisks if Windows thinks there is not enough room on the system disk. This leads to different disks being adressed and produces such waiting times that block the CPU and trouble the realtime audio (this is only my unofficial clumsy explanation, I am sure somebody else can explain it in more detail).

So imo it is worth trying to either 1. restrict the pagefile to one SSD drive or 2. try disabling the pagefile alltogether (this one more for analysis than for actual work probably). You can edit the pagefile settings by right-clicking My Computer and selecting Advanced System Settings->Advanced->Performance Settings->Advanced->Virtual memory->Change.

I've just having luck with this fix on a computer that had a C drive filled to 85% (always a bad idea) and began stuttering massively. After disabling the pagefile the stutter is totally gone. Therefore I believe that even with more room on the system drive it can happen that windows opens a second or third pagefile on other disks and that obviously can cause realtime latency problems.

More information about pagefile problems (look for the keyword "hard pagefaults"):
http://www.resplendence.com/latencymon_using

Hope that helps, Hannes
 
Last edited:
Great video and interesting thread. I agree with your suggestions in the video about the most likely culprits - wifi cards can be a pain, so can other interfaces like bluetooth and even good old USB devices - even some really basic devices like MIDI hubs can cause a dropout.
 

chimuelo

Star Of Stage & Screen
I have excellent real time performance but still want to check out the paging file tip from Hannes.
I believe disabling all USB ports helps too.
I found years back when messing with IRQs that disabling ports still allows them to power up Hardware controllers.
In recent years IRQ tweaks aren't needed but the disabling of USB ports still works for me.
But most of all I use the XITE-1 DSP rack as my soundcard.
96k works great but wastes resources.
But 64 samples @ 48k and 2.2 msec. Duplexxed is great for real time.
It allows me to run all digital I/Os to hardware which saves me lots of juice as I avoid ASIO FX.
Just prefer native dynamics and non time based FX.
Saves resources and sounds better too.
 

Wibben

Active Member
Great video, rgames!

I'm not finding I'm having any issues with my i7 4820K, but when I mixdown a project that is about 5 minutes long and not particularly heavy on tracks, my CPU doesn't even go above 20% workload (when I monitor the performance), but the mixdown takes about as long as the song. The disk isn't that stressed either.. is there a setting I might be missing?

I'm using Cubase 8 pro. Shouldn't the mixdown use as much power as is available?
 

FriFlo

Senior Member
LatencyMon (I am on Windows 8) tells me, my system is suitable for handling real-time audio! Great news! ;)
But there is one strange antry in the report:

Code:
CPU SPEED
_________________________________________________________________________________________________________
Reported CPU speed:  3302 MHz
Measured CPU speed:  1 MHz (approx.)

Note: reported execution times may be calculated based on a fixed reported CPU speed. Disable variable speed settings like Intel Speed Step and AMD Cool N Quiet in the BIOS setup for more accurate results.

WARNING: the CPU speed that was measured is only a fraction of the CPU speed reported. Your CPUs may be throttled back due to variable speed settings and thermal issues. It is suggested that you run a utility which reports your actual CPU frequency and temperature.
That is kind of strange and does sound like a program error to me, because 1 GHz is pretty unlikely. It may however be a problem, because - if I remember correctly - I did not connect the fans to the mainboard. Didn't have any temperature problems, though. I just thought, I'd ask, what you other Win8-guys have in your report ...
I also got some hardepage faults, but according to the report they are only relevant, when audio programs have them. Only exception: Cubase creates quite a lot of hardpage faults during start up and shut down. None, however, once it is running. Normal, I guess?!
I get, that you actually prefer DPCLatencyChecker, Richard. But I have some problems with dropouts, slowly loading VEpro and unresponsive Cubase sometimes, so I thought that maybe those other readings could give me a clue, why that is.
 

EastWest Lurker

Senior Member
Great work Richard! One minor suggestion: a lot of what you talk about with the Bios, various video cards, are mostly PC only issues as Macs are designed to include components that work together optimally and higher quality than some PC makers or DIY guys choose. So perhaps the tile should read:

CPU Performance vs. Real-Time Performance in Your PC DAW
 

FriFlo

Senior Member
Great work Richard! One minor suggestion: a lot of what you talk about with the Bios, various video cards, are mostly PC only issues as Macs are designed to include components that work together optimally and higher quality than some PC makers or DIY guys choose.
Yeah, thats right. Macs are coming with a bad realtime performance due to the weak components right from the factory! ;)
 

kclements

Active Member
Really enjoyed the video, Richard. Even being a Mac user, great info! Thanks so much for posting. Looking forward to future videos.

Cheers
kc
 
OP
rgames

rgames

Collapsing the Wavefunction
Shouldn't the mixdown use as much power as is available?
It depends - the first thing to do is to make sure you don't have the "Real-Time Export" option enabled in the export dialog box.

If you are exporting non-real-time then there are a few things that can be going on, none of which is unusual. If you're using VE Pro over ethernet then that can be a bottleneck (though I've not experienced it on my systems). Likewise, there are some plug-ins and VIs that just don't work much faster than real-time. I run in to that on some projects, as well. In those instances the CPU is still just sitting around waiting for something else to happen.

You can see that in the video I posted - when I export the audio the CPU usage is higher than in real-time but still not 100%.

Same thing with the video rendering - some video processing doesn't make use of all processing power so when you render you get less than full CPU usage. I don't have a good explanation for why that is but it's clearly not related to CPU power. There's some other process - transfer of data perhaps - that doesn't involve the CPU, so it's sitting around while that's going on.

rgames
 
Top Bottom