Modartt user forum - Organteq's 'Audio Load' meter vs. Task Manager's 'Performance tab'

Re: Organteq's 'Audio Load' meter vs. Task Manager's 'Performance tab'

2022-05-04T20:12:30Z

wjlljam wrote:

I have cpu overload problem in Organteq only when I use full organ, with all stops activated. It is impossible to play. Such a problem does not occur for example with Sweelinq. I notice that when using Organteq, even configured to use all 8 cores of the i7, only the first core is used and when I use large polyphony with full organ, the first core goes from 100% instead of looking for other cores to work, inside or outside the DAW, which is not the case with other software where there is a perfect distribution between the cores.

It is a strange situation you mention. I suspect some setting should be modified to give Organteq access to the full processor power: Please go under 'Options' to 'Perf' to find information of the processor. And make sure that the checkbox 'Multicore rendering' is activated.

And that your operating system (which?) allows that as well. Under Windows start the task manager via Cntrl-Alt-Del and check under the tab performance the number of physical cores.
Second: type msconfig in the search window and run that program as adminstrator. Go to the boot tab and the box 'Advanced options' and make sure that the check box next to 'Number of processors' is UNchecked. That should allow Windows to use all cores. After OK, restart.

I use Organteq stand-alone on a PC with W10 Prof and I7-9700K as processor running at 3.6 GHz, audio at 384 samples at 48 kS/s. The 8 cores are working hard when full organ is used with 12 keys pressed, but it manages without overload.

Sweelinq is a sampled organ with reverb added, and required much less processing power. On that topic it can not be compared with Organteq.

Re: Organteq's 'Audio Load' meter vs. Task Manager's 'Performance tab'

2022-04-24T16:57:24Z

I have cpu overload problem in Organteq only when I use full organ, with all stops activated. It is impossible to play. Such a problem does not occur for example with Sweelinq. I notice that when using Organteq, even configured to use all 8 cores of the i7, only the first core is used and when I use large polyphony with full organ, the first core goes from 100% instead of looking for other cores to work, inside or outside the DAW, which is not the case with other software where there is a perfect distribution between the cores.

Re: Organteq's 'Audio Load' meter vs. Task Manager's 'Performance tab'

2021-01-18T19:08:20Z

Good point, Alex.

nseljan, are you still have issues or did the problem go away?

Re: Organteq's 'Audio Load' meter vs. Task Manager's 'Performance tab'

2021-01-18T14:34:41Z

There might be a simpler explanation: the time resolution of the Audio Load is much finer that that of the task manager. Windows seems to average over a second. And Organteq requires much processing power at the (short duration) onset of the pipes.

Re: Organteq's 'Audio Load' meter vs. Task Manager's 'Performance tab'

2020-12-28T16:14:19Z

Most likely it's some aspect of processing that's core limited in some way, particularly as 3/8 is roughly 37%. I don't have the knowledge of the developers on what aspects are multicore and what aren't. It's even possible that, depending on the OS, if you're using a motherboard-based sound device or WDM sound driver, the OS or chipset is blocking how many cores can be used for audio processing.

Organteq's 'Audio Load' meter vs. Task Manager's 'Performance tab'

2020-12-26T23:45:25Z

Hi all,

I was wondering, for those of you who are getting audible cracks due to CPU overload, how do your Organteq's 'Audio Load' and Task Manager's 'Performance tab' correlate? I'm running an Intel i7-2600 and, with enough stops, I'm getting cracks with 'Audio Load' meter showing red lines for CPU overload - but, looking at CPU graphs within Task Manager, my CPU doesn't appear to go over 37 % utilization at any point.

I'm trying to understand what is happening here - perhaps Task Manager is misreporting, or there is some other reasonable explanation here. :-)

Thanks for sharing your thoughts.