Determining where CPU peaks come from

[pinkcanaru]

After Tony Ostinato pointed me (us) towards the Razer Game Booster app from iobit I began to think about why we see peaks and valleys in the CPU meter of Cantabile and any other DAW.
I'm not sure the Razer does much more than any savvy person would do with regard to tweaks, but I'm still checking it out. In the meantime, I would love to find out why a selection of plugins which idle at around 10% suddenly peak up to 30 or 40%.
What is it that interferes? What PC processes can drag that much resource away and can it be identified?

I know this is a hot topic for those who are using computers live.... it's a totally different ball game from the safety of the studio. If you have to reboot - if something clicks - if it takes 5 minutes to sort out an issue, who really cares?
In front of an audience... a lot of people care. You, the people you work with - and the audience.

I would love to find a surefire way to kill those periodic processes which cause the CPU to jump. Anyone got any suggestions?

[TiUser]

I don't really know, but maybe killing windows is the best solution...

My best guess is gui activity. VST's contain gui too and gui activity can cause peaks. Even windows itself gives processes / threads more cpu cycles when it assumes it will be usefull to boost gui response. I guess it's difficult to compensate that in any way - except keeping VST gui's closed which may help sometimes.

The best idea I came up with is separating gui and audio/midi processing in two separate processes (= programs) that communicate via a special pipe. That's some effort to program as anything to control needs IPC (inter process comunication). But that way I found fast cycling audio and midi processing gets more reliable on the cpu. I've additionally a special core affinity with my processes, even cores (#0, #2) are assigned to the gui process (I observed that on my machine these cores are also preferrably in use for other gui processes and have higher dpc latenxies than the other cores). The audio process affinity goes to the odd cores(#1, #3), so gui activity hardly influences timing as it is scheduled to the other cores and runs also HW wise in parallel.

Finally I've experimented influencing the scheduling quantums as some media players do, which makes the windows scheduler less lethargic but also increases a bit the basic load on the cpu for the scheduler itself.

This is more or less what I can tell. Finally I have no clue if these strategies work on other cpus or HW the same, and maybe some results change with the next OS updates and service packs...

If you want a perfect load behavior you need another OS than windows. I stick with this statement.

[pinkcanaru]

I kinda guessed you'd say that
All GUI's are closed.
What I need is a diagnostic tool which identifies the source of spikes.

[TiUser]

I kinda guessed you'd say that
All GUI's are closed.
What I need is a diagnostic tool which identifies the source of spikes.

All I want to say is it's very difficult on windows to get most of your cpu power for audio... Just usual standard programming knowledge (like mine) doesn't help much here. This seems to be kernel experts business - if it's possible at all to tweak windows to get what we need here...

Resplendence "LatencyMon" gives quite detailled informations. The home edition is free.

See: http://www.resplendence.com/latencymon

But I guess you know this tool already, do you?

With my C# project I use some System.Diagnostics calls and interop stuff to wimm.dll to accomplish what I've talked about above. I'm also using an professional audio lib with C# wrapper which is technically win32 stuff. That's all of my hot knowledge - and it took me a long time to collect all that...

[tombuck]

Windows certainly isn't to blame, its just a simple matter of configuring the hardware and hardening the OS for a single purpose workload such as DAW, or more specifically, DAW for live performance.

The load meter in Cantabile isn't a CPU meter, so if you are referring to "CPU peaks" using that meter from Cantabile, you are likely actually referring to DPC loads instead. Actual CPU peaks alone won't necessarily cause audio problems, but if you have a weak processor, it only makes things more difficult. Excessively long DPC queues on the other hand absolutely will cause audio problems. The key is minimizing DPC loads (and IRQ conflicts) which is done primarily through disabling as much hardware as possible. Something as simple as disabling Wireless and all networking before playing can make a big difference. Running the latencymon tool as well as the DPC Latency Checker, http://www.thesycon.de/deu/latency_check.shtml can help you tweak your DPC loads.

Also keep in mind, some VST's simply behave in strange ways. Just expect that especially if you have a large mix of free and commercial VST's. The key here is to give as much headroom to the VST's and host as possible.

if you are trying to use your laptop as both a productivity device and a DAW, you'll probably not achieve optimization for either. You might want to consider having 2 hard drives that you swap depending on what you are doing.

There are plenty of resources online to help tweak Windows for DAW, I know M-Audio has an extensive guide out there, and I've seen a few Youtube videos.

[cron]

Do you have Windows set to its 'high performance' power plan? I've found my machine often doesn't respond to VST load as you'd expect when using the default 'balanced' plan that, in theory, should instantly respond to demand. Odd, as the balanced plan usually whacks the processor up to max speed and keeps it there whenever I use other intensive softwares. Maybe it's a DLL vs EXE thing or somesuch.

[pinkcanaru]

Could be useful.

[TiUser]

Interesting tool.

Noone tried "LatencyMon" yet?

DPC is important but it's not that simple as DPC is much different on the several cores of a multi core cpu... If you don't use the cores with heavy DPC load for audio things better.

There is another metric called "interrupt to process latency" that influences audio. If a processes' thread needs 2ms to start running and audio needs to be refreshe every 3 ms (128samples@44.1kHz) only 1/3 of cpu power can be used for audio or in other words audio load is 3 times higher than expected from pure cpu load. The larger the buffer size the less important is this latency.

You can tweak and do what you want - to my current knowledge Windows offers no control to keep master on what's goin on. (if you do I'm hot to learn more about it) Yes you can optimize here and there but the principle of lack of control remains. Or in other words all these tweaks would not be necessary on a system that keeps audio under control.

There is a misunderstanding between practical optimization (which can work fine and does if processing power increases while audio demands don't) and the principle of a 100% reliabls system resources control for audio by an OS.

In my eyes two things are missing with current VST technology. One is that plugins would have to report their maximum processing needs and second an OS that can check and control this without creating cracks and pops. It's obvious that this can work only with leaving headroom too but the difference is you know in advance what works and what not and the system can take automatic actions - freeing us from all the "optimizations" gettings us back to concentrate on making music.

[UltraJv]

Interesting tool.

Noone tried "LatencyMon" yet?

DPC is important but it's not that simple as DPC is much different on the several cores of a multi core cpu... If you don't use the cores with heavy DPC load for audio things better.

There is another metric called "interrupt to process latency" that influences audio. If a processes' thread needs 2ms to start running and audio needs to be refreshe every 3 ms (128samples@44.1kHz) only 1/3 of cpu power can be used for audio or in other words audio load is 3 times higher than expected from pure cpu load. The larger the buffer size the less important is this latency.

You can tweak and do what you want - to my current knowledge Windows offers no control to keep master on what's goin on. (if you do I'm hot to learn more about it) Yes you can optimize here and there but the principle of lack of control remains. Or in other words all these tweaks would not be necessary on a system that keeps audio under control.

There is a misunderstanding between practical optimization (which can work fine and does if processing power increases while audio demands don't) and the principle of a 100% reliabls system resources control for audio by an OS.

In my eyes two things are missing with current VST technology. One is that plugins would have to report their maximum processing needs and second an OS that can check and control this without creating cracks and pops. It's obvious that this can work only with leaving headroom too but the difference is you know in advance what works and what not and the system can take automatic actions - freeing us from all the "optimizations" gettings us back to concentrate on making music.

How would a vst tell you it needs more CPU? Its a hardware problem so it wont help. That feature would cause so much trouble as it would show you need faster CPU on heavy projects, people would be complaining all the time, it would be a support nightmare. Plugs like Diva will take all they can get if you put settings on max. It cant recommend a CPU upgrade though Windows does have a process priority mechanism built in, its best managed by the OS though. Video processing situation is the same. It comes down to buying the right machine for the job, knowing your needs beforehand. That's why realtime audio/video is a specialist area, always will be. As for needing another OS than Windows, rubbish.

How to change Windows process priority :

http://www.wikihow.com/Change-Process-P ... sk-Manager

[TiUser]

It is not impossible to calculate processing needs of code - HW makers are forced to do that, they can't use DSP resources that are not there.

Plugins like Diva need to be set into any mode to determine/limit cpu needs. However you suggest implicitely that this cpu demand process is a static one. There could be more flexible models, like per patch or per note demand to control things more granular. I know all this is future - but if no one thinks about it it will never be considered.

However VST's reporting their cpu needs make only sense if the OS can deal with it and hosts use it. So currently it makes no sense on windows. It's a discussing topic.

We are discussiong real time audio with low latency here.

Processing video is a totally different thing. Windows scheduing is quite good at distributing tasks of non realtime calculations. Modern video software also use the graphics engines and GPU's of graphics cards (like cuda). But where are the "APU's" for audio processing?

Even studio track by track audio recording is much less demanding as you can increase buffer sizes, use direct monitoring and latency compensation of the DAW. This is how you can record hundreds of tracks on an average PC.

I am not familiar with realtime video but that's probably similar - except that scheduling slices are much larger in range of the framerate.

Suggesting to manipulate windows process priorities is not the point. The relevant business is some floors deeper than that.

But I agree that unless software gets better design realtime audio is a kind of experts business. It's like an old story where processing tomograpic data used to need about an hour or so. Then mathematic experts refined the algorithms and the process finishes now in minutes - on the same machines... It's not only brute processing power that makes a difference, it's using it clever. And this is experts business too... but for the benefit of us all, not just pc industry, happily selling us the next gen every year while we waste cpu power with current audio processing strategies on PC's...

Just to end with, "realtime" does not mean "as fast as possible", it means right in time, just as fast as needed.

[tkmh]

Questions for TIuser and all:

Wouldnt using newer upcoming audio interfaces designed around USB 3.0 and/or Thunderbolt kind-of
get us in the same direction as far as latency and better CPU usage?

ex:

http://www.sonicstate.com/news/2013/04/ ... interface/


And/or a newer updated ASIO (3,0?) standards for our newer PC's. Isn't ASIO2 about 10 years
old now?

regards,
tkmh

[pinkcanaru]

Good ASIO drives and hardware are an essential part of achieving good, low latency performance. If USB 3.0 devices with excellent drivers come to market, then that can't hurt.
As noted over on the 'is anyone using Cantabile live and no hardware' thread, people are running systems solidly with buffers of 32 samples all the way through to final mix with ASIO 2.0.
The protocol can handle low latency. The hardware is the limiting factor.

(Edited because I wrote ASIO 3.0 instead of USB 3.0)

[TiUser]

I think the ASIO drivers and how they work in windows are the most important part to get the most out of the cpu power we pay for.

USB bandwidth need is relative to the number of audio channels and sampling rates. You don't need USB 3.0 for a simple stereo in/out.

But as far as I have heard USB 3 will also improve the communication protocol in a beneficial way for streaming audio.

So all in all I think it's no reason to rush into USB 3. It will take some time 'til music gear will support USB 3. But it's for sure worth observing new gear incorporating USB 3.


Finally old standards must not be outdated just because they are old. Midi is by far older and still in use because manufacturers are unable to agree to something "better" because everyone want's it's own proprietary "standard"...