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



## rgames

Perhaps of interest to the folks here - I've found that the difference between real-time performance and CPU performance is one of the most-misunderstood elements of DAW performance. I've discussed it a bunch of times with a bunch of folks here and elsewhere, so I thought I'd put a video together to explain the difference so I can save myself some time the next time it comes up 

Hopefully you'll find some useful info in this video.


----------



## stonzthro

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!


----------



## Mike Marino

Thanks for making this video, Richard. Very informative!


----------



## Martin K

Thank you Richard. Very informative!

best,
Martin


----------



## rgames

Thanks for the kinds words - I love doing these sorts of things.  I just can't seem to find the time - the last one was over a year ago...


----------



## synthpunk

I feel smarter now 
TX


----------



## jamieboo

Excellent video - thanks Richard!
This is very relevant to me at present. About to be building a new X99 system with a i7 5820K cpu.
I by no means am assuming that things are going to be great simply because that's a good chip.
Trouble is, I'm having real difficulty finding out in advance what components are likely to cause problems. I'm at the 'what motherboard' stage at the moment, and I'm vigorously stumped! I guess I just need to find other people with X99 systems using East West Hollywood Orchestra in Cubase and then ask what components they've found work nicely.
Thanks again for the video!


----------



## ryanstrong

Thumbs up, thanks Richard!


----------



## Andrew Aversa

Wow, this is absolutely fantastic. So useful and well-explained. I'm going to link this to people from now on.


----------



## dtonthept

Richard, this is brilliant, thanks so much! Your last video was really helpful too.


----------



## Vin

Great video. Keep them coming!


----------



## FriFlo

Great video! Why don't those latency checkers work on windows 8?
Edit: never mind! I just checked their web site. Hint for windows 8 users: LatencyMon does already work with windows 8, as far as I can tell.


----------



## tack

I miss my preemptable kernel every time I boot into Windows. Booting out of Linux into Windows feels like going back to the dark ages. Now if only Linux had the software ...

Thanks for the video, Richard.


----------



## Przemek K.

Richard, that's a great video. Keep em coming


----------



## vicontrolu

This is video is just as awesome as scary.

Thanks so much Richard.


----------



## Hannes_F

Thanks so much Richard. A class act all the way.

The Thonex test comes to mind ... those were the times


----------



## jamwerks

Very helpfull info! Thanks !!


----------



## OleJoergensen

Thank you for so generously sharing this video!


----------



## amsams

Thank you for this video. It's so nice to see a DAW-specific explanation for why CPUs struggle.


----------



## gdugan

Fantastic informative video, Richard. Thanks!


----------



## Blake Ewing

Great work, Richard!


----------



## Markus Kohlprath

stonzthro said:


> 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!


----------



## chimuelo

Great gift from an experiencd DAW man.
Thanks


----------



## rgames

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

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)...


----------



## rgames

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

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?


----------



## Hannes_F

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


----------



## Wooloomooloo

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

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

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

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.


----------



## Black Light Recordings

Big Thanks!


----------



## EastWest Lurker

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*


----------



## Leo Badinella

Nice video Richard. Thank you for doing it!


----------



## germancomponist

Yeah, that's it! Well explained and also a great vid, Richard! Well done, Sir!


----------



## FriFlo

EastWest Lurker said:


> 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!


----------



## germancomponist

FriFlo said:


> Yeah, thats right. Macs are coming with a bad realtime performance due to the weak components right from the factory!


Huh ....


----------



## kclements

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

Cheers
kc


----------



## rgames

Wibben said:


> 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


----------



## rgames

EastWest Lurker said:


> 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*


Maybe I don't completely follow but it sounds like you're saying Mac users don't have latency problems. That's clearly not the case, hence the reason for my confusion. I almost never have latency problems with my PCs - the last 3-4 machines I've built run just fine at 128 samples with no tweaks to anything (except the laptop shown in the video, but I haven't seen latency measurements on a Mac booting from a PCIe SSD either). But clearly there are folks who do have problems with PCs. The only thing PC specific in the video was the mention of the latency checker tools. I assume there are similar tools for Mac but I'm not sure what they are.

Regardless, Macs use all the same hardware that you get from HP or Dell or VisionDAW or whomever. Macs still have a BIOS. Macs still have video cards and hard drives and USB hubs that interrupt the processor for processing. And all of those devices are the same as on PCs. It is true, of course, that you have fewer options to tweak those devices on a Mac. But it's not because they're different or non-existent.

So I think the video applies perfectly well to both Mac and PC.


----------



## rgames

And to the hardware purists out there - someone pointed out that EFI is used in place of BIOS these days. Yes, it is - but I'll probably be calling it BIOS for a long time to come


----------



## EastWest Lurker

rgames said:


> Maybe I don't completely follow but it sounds like you're saying Mac users don't have latency problems. That's clearly not the case, hence the reason for my confusion. I almost never have latency problems with my PCs - the last 3-4 machines I've built run just fine at 128 samples with no tweaks to anything (except thNo e laptop shown in the video, but I haven't seen latency measurements on a Mac booting from a PCIe SSD either). But clearly there are folks who do have problems with PCs. The only thing PC specific in the video was the mention of the latency checker tools. I assume there are similar tools for Mac but I'm not sure what they are.
> 
> Regardless, Macs use all the same hardware that you get from HP or Dell or VisionDAW or whomever. Macs still have a BIOS. Macs still have video cards and hard drives and USB hubs that interrupt the processor for processing. And all of those devices are the same as on PCs. It is true, of course, that you have fewer options to tweak those devices on a Mac. But it's not because they're different or non-existent.
> 
> So I think the video applies perfectly well to both Mac and PC.



Richard, all I am saying is that Macs come universally with optimal choices for their hardware and there are no Bios settings to tweak for audio. while PCs run the gamut, although as you say, the best ones use high quality stuff. There has to be a reason however why when I was looking to get a slave PC, so many people who are knowledgeable told me essentially _"stay away from PCs you buy in a store from HP or Dell, etc. they are not good for audio work. DIY or get one from a company like VisionDaw."_

Unless you think they all were wrong?


----------



## Gabriel2013

Thanks Richard for your contribution to the community. 

But after watching your video, I am more confuse about my next server built.
I am deciding between 4790K, 5820K and 6700K.

My instincts tells me to go with the 5820K, but according to Richard speed is more important than cores (for sample streaming).
If some one can help me with the following questions I really appreciated.

. Those VEPRO take full advantage of multi-cores and multi-threads or it´s a urban myth?
. Is DDR3 a better real-time performance than DDR4 (because of CAS)?
. For sample streaming only, those the i5 6600K benchmark similar to i7 6700k?

Thanks
_Gabriel


----------



## kdm

Very nicely done Richard. Just came across a question on this on another forum and referred them back here.

Gabriel2013 - I think VEPro may be somewhat of a deviation from the general cores vs. speed rule since it does split processes. I don't know for sure, so this is just my hunch that both speed and cores will help VEPro (perhaps speed having a slight edge in importance), but speed would be more useful for VIs within a DAW. This would be a good question for the folks at VSL.


----------



## ptsmith

Thanks Richard. I've implemented some of your suggestions including lowering my RAM speed and seeing about a 30% increase in DAW performance.  Oddly I'm getting even worse CPU performance. It went from 40-45% usage to 32-35%.

On my DAW LatencyMon shows exactly what you said about the majority/all of the interrupts going to one core.


----------



## brett

Lowering RAM speed? Was that in the video? I must've missed that

Have you done this in the bios? XMP profiles?


----------



## ptsmith

Yes it was mentioned in the video. I lowered it in BIOS.


----------



## Hannes_F

Made this thread a sticky on user request (and I agree).


----------



## Resoded

Richard, thanks very much for taking the time to make that video. Very educational.


----------



## bcarwell

THANKS Richard for taking the time. A few folks may carp about a few nits, but you have performed an amazing service. Not to mention how professionally well-produced with graphics and animation, clear, and entertaining your talk is. You have a very real talent for addressing a highly technical issue in an extremely articulate, clear, thoughtful, organized and informative manner. Not bad for an aero. (BTW your prior system design video was equally first rate). So many folks are techies but cannot formulate an English sentence or communicate or they are good communicators and musicians but weak and often ill-informed in informational content. You've got them both in spades. I hope you will continue with these, and I noted that recently this has now been made a well-deserved stickie on vi-control.net. I'd sure love to see future videos on how your produce your music, e.g. template design, workflow, library selection, reverb, etc. Excellent work from a big fan awaiting more.


----------



## snattack

http://www.soundonsound.com/sos/jul15/articles/cpu-performance-0715.htm

More cores = better performance.

Multi-CPU = worse performance than one processor with the same total amount of cores.

Other factors with different stuff hogging the realtime chain is another thing of course. But the same motherboard with more cores equals better RTP.

Macs don't have a BIOS, they have EFI. And OSX is programmed differently than Windows when it comes to RTP, with driver priority and such.


----------



## Letis

Thanks for this good explanations!


----------



## neblix

EastWest Lurker said:


> There has to be a reason however why when I was looking to get a slave PC, so many people who are knowledgeable told me essentially _"stay away from PCs you buy in a store from HP or Dell, etc. they are not good for audio work. DIY or get one from a company like VisionDaw."_
> 
> Unless you think they all were wrong?



No one is trying to assert that HP/Dell computers are optimal for finely tuned workstation performance.

You are correct however that PC's require more manual tuning than Macs. Though this is not because of quality of parts, on the contrary, good DIY computers have way higher quality parts (such as power supplies and extensive motherboard technologies) than anything Apple or any other computer brand will ever offer to consumers because those latter components are designed with size and power constraints (so they often must compromise on the full capabilities of DIY hardware you'll find).

It's mainly because Apple and its programmers are allowed to make many assumptions about the hardware their software will run on; as such, many hard optimizations can be made that normally aren't possible in normal software development practices (which cater to maximum portability and scalability at the expense of hard optimizations). Because they have a history of using specific technologies that they never deviate from, they only have had to solve their issues like compatibility a long time ago, whereas in PC-based systems it's a recurring challenge since the hardware market is bigger, with more players, and everyone is given a fair chance.

You must realize though that in saying this, it's functionally equivalent to observing that a heavily modified monster of a race car made from various high end parts and assembly techniques requires more work than buying a Lamborghini. It *is* more work, but also way more reward in both flexibility and performance.

Of course this doesn't factor that you lose OSX on a PC, which is of course important to consider. Lamborghinis are stylish and fast, nothing wrong with them, I'm just clearing up that PC's do in fact have sizable benefits in multiple areas that make them a viable counterchoice to Macs.

PC's can be every bit just as if not more stable, fast, powerful, etc. than Macs if you dig deep enough. And it will cost less money, too.


----------



## Alatar

Very pedagogical video. Thanks. 

Here is a more technical video, which higlights the locking/latency problems of audio real-time programming (in C++):


----------



## peksi

If I were to increase audio buffer a lot would I be able to reap the benefits from multi cpu system? That way the real time demand would be easier to fullfill - comparable to the audio mixdown process in Cubase which seems to utilize all cores to the max.

I have no need for live performance as I only do studio composing. I would gladly trade a slight lag for more power.


----------



## rgames

peksi said:


> If I were to increase audio buffer a lot would I be able to reap the benefits from multi cpu system?


Up to a point, yes. But once the buffer is large enough then it won't make a difference if you increase it further. Where that point falls depends on your system and what you're trying to run. In my experience, it tends to be around 1024 samples. I think most audio interfaces don't offer buffers much higher than that for that reason - it doesn't make any difference.

Pretty much all DAWs take advantage of multiple CPUs, though, so that's not really a multi-CPU problem. Regardless of the number of CPUs, the total system performance will be better with a larger buffer *up to some point* because you're reducing the likelihood of real-time-audio limitations. But then, at that point, other limitations start to dominate.

In general, even audio mixdown can't use all available CPU power because it still has to wait on other subsystems to do their things (like the disk). Rendering video is different because it is working mostly in RAM and transfer to/from RAM is much faster than transfers to disk or the audio interface. The calculations take the majority of the time, so video rendering tends to be much more CPU limited.

Cheers,

rgames


----------



## jason_

Thanks so much for this!! Very informative


----------



## peksi

What is beyond my understanding is that why most DAW manufacturers have dual Xeon models at the top of their line? Based on the knowledge in this thread those DAWs perform RT-wise worse than their single CPU counterparts. Or do they know something we not?


----------



## David Hall

rgames said:


> Perhaps of interest to the folks here - I've found that the difference between real-time performance and CPU performance is one of the most-misunderstood elements of DAW performance. I've discussed it a bunch of times with a bunch of folks here and elsewhere, so I thought I'd put a video together to explain the difference so I can save myself some time the next time it comes up
> 
> Hopefully you'll find some useful info in this video.



wow... thanks Richard.

quick question is there a way to find out what part of your computer is causing the lock-up? like a troubleshooting way to figure this out?


----------



## Shad0wLandsUK

rgames said:


> And to the hardware purists out there - someone pointed out that EFI is used in place of BIOS these days. Yes, it is - but I'll probably be calling it BIOS for a long time to come


If you want to be really particular it is UEFI or (uEFI) Unified Extensible Firmware Interface) and yes I am sad enough to know that off-by-heart :/

For Macs until recently (I believe they now use the full specification) Apple only used custom-EFI, as they were only utilizing a substrate of the EFI standard

I do understand however that with Windows 8 they began to implement more and as of the release of Windows 10 they use the full spec to support Secure Boot for Windows with Bootcamp

Sad techy here, who lives in the basement


----------



## ironbut

What an awesome video Richard!
Thanks for making this subject clear enough for thick headed guys like me to understand!


----------



## johjoh

*Still the best information on the subject* !!! I saw the videos on youtube in the past, but want to thank the author again for the insight.

Unfortunately, in real life - unless you have the budget / time (or technician) to experiment - it's not so easy to implement. 
1) You can't base serious decisions on specs only - that is if you (can) have real specs of all the subassemblies/parts and how they're integrated
2) Products are (dis)appearing continuously, and manufacturers change part sourcing / implementation during product lifecycles, etc. 

The monitoring tools are a help - unfortunately windows-only afaik :(

_BTW : willing to pay for a OS X realtime monitoring tool similar those mentioned in the article/videos !!_


----------



## Fredeke

I'm spreading the link around.


----------



## Dewdman42

One of the best technical explanation videos I have ever seen! Hope the author will make more on other topics.

Regarding OS X macs, its important to understand that OS X uses an entirely different mechanism to handle low level drivers then windows. Windows uses something called Deferred Procedural Call (i.e., DPC), and it has to do with the fact that Windows operating system is interrupt driven. There are pros and cons to being interrupt driven, but one of the cons is this symptom called DPC latency. OS X does not use that mechanism at all. I'm not exactly sure right now what OS X does do, but it does not do DPC. So there is no point to worrying about whether your mac has high or low DPC latency since we don't have a DPC latency checker utility..its not relevant. There is no such thing as DPC in OSX. OS X works a little differently.

That being said... There actually is a built in command line utility in OS X for monitoring latencies... when I run it, they are all low enough to not cause any concerns...so I don't know what OS X is doing differently, but knock yourselves out..its called */usr/bin/latency.* From the command line you can type '*man latency*' to read more about it.

Much of this video is still extremely good information for musicians, regardless of whether you're using OS X or Windows, in terms of understanding that neither computer is an actual real time computer. It operates on buffers and gives an illusion of real time operation, with buffer latency in the sound card being the thing that enables that to happen. We make music in real time, but the computer is processing things and timesharing different components of the system. Very well presented video here and applicable to both platforms, except for the DPC section.


----------



## TimRideout

Amazing! Thank you so much for this. There has been talk of modifying one's RAM speed in this thread - but I watched the entire video, and saw no such thing on that topic.

Could someone enlighten me as to the "slow your RAM" theory?


----------



## DAW PLUS

RAM speed is not an issue for audio. New Ryzen CPU's may benefit from it but the effect for realtime audio is marginal.


----------



## José Herring

Finally got around to Watching this. Totally Great! It explains why my 10 year old machine still runs circles around a lot of other machines. The DPC latency is way lower on that machine than my other newer ones. 

Great reference to start building my new DAW.


----------



## snattack

Again, pointing out that several tests from multiple users (including a long Gearslutz thread containing Logic project to test RTP) and a Sound On Sound article, etc, disproves the theory that multiple cores does not increases RTP. This is especially true for script heavy Kontakt patches that uses multi-core processing to handle non-audio related instructions. Also, this video is even less actual today when plugin and DAW manufacturers have optimized their software for multicore use.

Would Apple and all specialized PC DAW Building companies lie about this without anyone discovering it? No.

Are there other factors that can affect RTP? Yes, there is. But disregarding those, multiple cores significantly increases Real Time Performance as long as the system doesn't have any other problems.

I linked the SOS article several years ago:





Multi-core Processors For Musicians


Some music applications will completely fail to take advantage of the multiple cores of a modern CPU — but which ones, and why? We find out, and advise on how you can make best use of however many cores your PC has.




www.soundonsound.com





Also this, a mix between old and new stats:








Logic Pro Multicore Benchmarktest ! - Gearspace.com


Originally Posted by KommanderKeen Trying to read through this thread but struggling to zone in on the bits that are relevant to me. I run Logic Pro fo



www.gearslutz.com





Test are conclusive.

Also, as several other in this thread has pointed out: This video has nothing to do with OSX. I did an extensive test with Mainstage when programming sounds for a musical theatre show last year, that concluded that Kontakt inside Mainstage (running single core because of multi-core utilization conflicts between Mainstage and Kontakt) increased CPU usage by double rather than running Kontakt in multi core outside Mainstage. With the exact same patches. This also disproves the "multi core doesn't affect performance theory, and Mainstage is very realtime sensitive since it's live playback. This was confirmed on 4 different systems.

I don't agree with the conclusion of this video, and there are plenty of sources to back that up. I can't say what the video author's specific template does for this theory, but in all my cases of building orchestral setups throughout the years, there simply one conclusion:

More Cores = Better Performance.


----------



## Dewdman42

unless you need low latency live, especially with a dense plugin stack or a really powerful synth plugin then it doesn’t.


----------



## bosDAW

Richard/anyone: I understand the all the basic concepts in the video, and it makes sense. My question was in regard to the *audio interface*

Is it possible that swapping in a newer interface using the same buffer settings (with DAW and all other hardware not changing) may improve how fast audio is processed and sent out of the speakers? That is, does the audio interface have a "clock speed" that may limit its ability to keep up with the amount of data coming in? Or is any working interface "fast" enough to process incoming buffer data such that the limiting factor will _always_ be another component earlier in the chain locking up the CPU?

I run a MacPro 2010 2.93GHz 12-core with Digital Performer 10.11, 64Gb RAM, internal SATA-2 SSDs mostly streaming, stock GPU (Radeon 5770), and an old MOTU audio interface (828 mkIII hybrid with USB2/firewire 800). On a large project (60 instrument tracks + 20 Aux tracks, 8 VIs with ~4-6 instruments each, ~40 plugins using mostly EQ) and using 1024 buffer size for mixing, I will get spikes/audio pops occasionally. I would be curious if a newer _interface_ would be faster/more efficient at processing incoming data vs if the problem is likely to be one of the SSDs vs maybe the USB2 spec is not enough to carry all the data. I also have a PCIe card for the SSDs and a PCIe card with NVMe available to use, but I am not sure if that would be the first thing to consider testing. Would love to hear some opinions. Great thread!


----------



## Dewdman42

when you're talking bout running at 1024 buffer size, I doubt the audio interface has anything to do with the CPU spikes and audio drops you're getting. 

Do you run in USB2 or firewire 800 mode by the way? Did you try with firewire to see if it makes any difference? I doubt it does though.

MOTU makes very good drivers for their interfaces. When you're talking about a large buffer, its really not an issue that the audio card would be the bottleneck. when you start going to smaller buffer sizes, then the buss itself could make a difference (ie, USB vs firewire, vs PCI vs thunderbolt, etc.). The faster busses (PCI) can go to smaller buffer sizes without swamping the cpu because they are more efficient at getting the data to the audio interface itself. Pretty much all mainstream audio interfaces, such as MOTU, can absolutely keep up with whatever USB is throwing at it... THAT (the motu) isn't the bottleneck. USB2 might be at lower buffer size settings, but at 1024...I don't think that has anything to do with the cpu spiking and dropouts you're experiencing..

that would have more to do, most likely, without whatever plugins you're using..


----------



## bosDAW

Dewdman42 said:


> when you're talking bout running at 1024 buffer size, I doubt the audio interface has anything to do with the CPU spikes and audio drops you're getting.
> 
> Do you run in USB2 or firewire 800 mode by the way? Did you try with firewire to see if it makes any difference? I doubt it does though.
> 
> MOTU makes very good drivers for their interfaces. When you're talking about a large buffer, its really not an issue that the audio card would be the bottleneck. when you start going to smaller buffer sizes, then the buss itself could make a difference (ie, USB vs firewire, vs PCI vs thunderbolt, etc.). The faster busses (PCI) can go to smaller buffer sizes without swamping the cpu because they are more efficient at getting the data to the audio interface itself. Pretty much all mainstream audio interfaces, such as MOTU, can absolutely keep up with whatever USB is throwing at it... THAT (the motu) isn't the bottleneck. USB2 might be at lower buffer size settings, but at 1024...I don't think that has anything to do with the cpu spiking and dropouts you're experiencing..
> 
> that would have more to do, most likely, without whatever plugins you're using..


Your explanation seems to make sense, and I have always had a good experience with MOTU units. After posting, I actually tried playing back the project with a 512 buffer size (normally, once I am in the mix stage I switch to 1024 out of habit, but I wanted to compare) and it still plays back with only one or two stutters over the course of a 10min track. Note that these are not necessarily clicks/pops but just playback errors, most likely due to too many VI tracks at the same time. This is especially true with Falcon, which loves eating CPU cycles. The only real problem is that sometimes making a change to something simple within the DAW software itself (e.g. turning the playback loop on/off) is enough to instantaneously spike the CPU and creates a loud, short burst of static that overloads the Master Fader. With SPAN open, it freezes the display in a "white out" state until I reset it by bypassing and then re-enabling. Aside from being annoying, I worry if this might cause damage to the speakers, even though I usually keep the monitor level fairly low.

It seems that this specific problem may have more with software and the DAW being pushed to the operational limit, the result being a sharp audio burst. I am running lots of Ozone 9 EQ and dynamics inserts, and I first experienced these spikes when bypassing/enabling a particular module, so I thought it may be an issue with the Ozone software. Overall (even at 512 buffer) the performance meters are ~50%, but the change of state (bypass/enable, loop, etc) is enough to momentarily spike everything. But it may just be too many VIs and plugins running already than the fault of any single piece of software or hardware.

(And the interface is using Firewire, with nothing else sharing the bus)


----------



## Dewdman42

which DAW are you using?


----------



## bosDAW

Dewdman42 said:


> which DAW are you using?


MOTU Digital Performer 10.11


----------

