Cantabile CPU report seems way off

[aMUSEd]

On my new i7 playing Bazille's most cpu intensive patch in the x64 and x32 versions I get nearly 100% cpu in Cantabile but the task manager is reporting less than 10% for 1 voice and no more than 20% for playing fast with 8 voices. Reaper also reports the same as task manager (in fact slightly less - Reaper is good at handling multicores). This is with multicore "aggressive" mode enabled.

This is a quadcore chip (well 8 if you count the hyperthreading)

[TiUser]

This topic has been discussed several times before here.

It has been said many times that Cantabile shows the realtime audio load - not the cpu load. This is not "way off", it's just something different you don't expect... It's also the "pessimistic" guess - or in other words, things really work below 100%...

I have checked other software where I got crackles without even being close to the 100% bar. Just it looks not so alarming and 50% of the crackles are hard to hear - but they are there too.

I don't know what Reaper displays but it seems to be simply the windows cpu meter. This value can indeed be lower than the total windows usage, when reaper just reports it's own consumption - that's alike the values you see when you examine the individual processes in task manager, these are also always never higher than the sum... Don't know if it's core processing is better. Maybe it is but I don't believe it's dramatically better like the meters suggest.

There is another point - the smaller the audio buffers become the more you probably note this difference between cpu meter and realtime audio meter. It's not there isn't enough cpu, it's about the cpu isn't free to be used in the moment it is needed - but switching threads / core context needs time too.

Did you do already a DPC test on you iX machine?

In a way I do not trust the modern iX processors. All the power saving tricks - now additional overdrive "boost" - seem not to help audio processing much, just cpu resources get more and more unpredictable for programs and this is an issue with realtime processing.

I also reported many times that you need to spread plugins over many racks to give Cantabile a chance to assign it to multiple cores. Or the other way round, how should Cantabile assign one plugin to multiple cores?

I've also used a plugin called "elephant" that does nothing more than burning cpu time. On my Quadcore this balances load nearly perfect over all cores. Pity that real plugins are very different in cpu need.

"Agressive" does only mean that multiple instances of the same plugin are tried to process in parallel when they are in different racks.

Balancing load over cores in realtime is one of the most challenging programming tasks I can think of and windows is the worst OS to try to archive this imho...

Having said that I also would like to see more efficient audio software but my guess is the problem is anywhere else - it's not the cpu, we have enough of this. There are other resources that set the limits.

Coming back to DPC this seems also be a lot related to other software like drivers which are not optimized enough to not disturb other realtime processing. Sometimes you benefit more to optimize your system than to upgrade to the next "better" HW platform.

I know that's frustrating and I hate it too - but it seems to be that way.

All this hassle is one reason why I strongly consider to get some HW again - at least when I would be faced the situation making music more serious than I currently do.

[TiUser]

I've taken the effort to compare Reaper to Cantabile.

Reaper isn't superior in audio performance - just the meters suggest this.

I've reported already about the jamstix issue with spiking audio timing load when its gui is open. So it's the ideal candidate for extreme tests... I've now checked in Reaper - and I get similar results! Reapers cpu meter reports much less than 10% cpu use but I get similar cracks in the audio stream under comparable conditions.

The difference to Cantabile is simply that Cantabile's timing load meter tells the relevant truth about audio load while a cpu meter can not and does not...

Reapers audio performance values look also illogical when you take latency, sample rate and buffer size. The only conclusion is that reaper uses many protection buffers by default.

Reaper does no magic - it just does not have a timing load meter. If it really performs a bit better you can not seriously compare that because of the lack of a similar meter.

Use your ears instead of load meters any you will find the true load in Reaper too.

[TiUser]

Maybe the meter in Cantabile should be called "ASIO load" meter and not cpu load meter. That's what I believe is the essential difference.

[asseca]

Actually it should be called "Process Time" meter. There is also the issue on how the "Process Time" is interpreted. If the time is averaged then it would not show when the "Process Time" is more than 100%.
Like with a good audio meter one needs to know the following "Process Time" values per audio thread:

1. average-time
2. hold "peak" time
3. hold last highest "peak" time/"overload >100%"

Especially 3) is of importance, that is when one gets those mysterious crackles. Unfortunately I have not found a single host which displays these occasional more than 100% "Process Times" ... It can happen that only one of the audio threads has > 100% process time and already cause audio crackles ...

[TiUser]

Thanks! Interesting insight.

However. I still think Cantabiles meter is more realistic than others who just display worthless windows cpu load - fooling us with the illusion of plenty processing resources which are not there for realtime audio.

[Zauni]

FYI, Jamstix 3.1 Beta 9 fixes the spikes in Cantabile.

[TiUser]

Thanks for the info.

I'll download that Jamstix beta and try it soon.

[Edit]

First check - MUCH better! No spikes any more.

Just Cantabile stalls as long as Jamstix takes to open it's gui window. But that's a negligible effect I can live with.