When Max's CPU DSP monitoring reaches 100% the cpu monitoring inside OSX's activity monitoring doesn't come above 40%. How can this be possible? Isn't Max using both the cores of my Core2Duo processor?

msp-starts-clipping-when-dsp-cpu-usage-crosses-40

I should add that it is possible to use multiple cores using a poly~. check out the help file for examples.

the strange thing is that MSP starts clipping when it crosses 40% of CPU usage (according to Max's DSP CPU monitoring).

In programs like Ableton Live this clicking starts when you cross 80%.

Why does this happen so fast in MaxMSP and what can i do (besides raising the IO buffer-size, it is set to 256 wich should be more then ok).

the strange thing is that MSP starts clipping when it crosses 40% of CPU usage (according to Max's DSP CPU monitoring).
In programs like Ableton Live this clicking starts when you cross 80%.
Why does this happen so fast in MaxMSP and what can i do (besides raising the IO buffer-size, it is set to 256 wich should be more then ok).


when i change my IO vector size up to 512 samples DSP CPU usage can get up to 55% without clipping but this is not acceptable for me.

how can it be that this clipping occurs at such low cpu usage?

putting the whole patch in a poly with the argument of 2 doubles the cpu usage. what would be the way to go to reduce cpu usage with the poly~ object?

A poly~ argument of 2 is telling poly~ to load 2 instances of the patcher, which is why the cpu useage doubles.

The poly~ reference file, under threadcount, states that the default number of threads to divide audio processing into is 2, which would mean that audio processing could be allocated to each core of the processor (assuming you have a dual-core).

To enable this option, you have to turn on parallel processing for that poly~ object, by using the parallel message, which is explained in the poly~ reference.

In your situation, using 2 instances of the patch in poly~ with parallel processing on and a threadcount of 2 would in theory split the audio processing between the two cores of the cpu, which should give you the same cpu load as using one instance outside a poly~.

Under parallel, the reference states "At this time, you cannot specify a single subpatcher on a different core. When enabled, this attribute splits up the number of voices between the number of processors available. It is primarily intended for patches that use a significant amount of CPU within multiple voices of the same poly~ object, and the multithreading overhead is primarily useful for larger signal vector sizes (at least 32 or greater). Other situations will not benefit."

So it seems that poly~ will not help the cpu load for your patch when used in this way.

Although it suggests that the max wizards are working on a way to make this possible. It would be an extremely useful option to have available for large patches.

I think the only way for you to use poly~ beneficially, is if there are duplicate audio processes in your patch which could be encapsulated/abstraction-ized and then loaded into a poly~. Then you could try playing around with the mute, threadcount etc.. options.

In your situation, using 2 instances of the patch in poly~ with parallel processing on and a threadcount of 2 would in theory split  the audio processing between the two cores of the cpu, which should give you the same cpu load as using one instance outside a poly~.  

Although it suggests that the max wizards are working on a way to make this possible.  It would be an extremely useful option to have available for large patches.

I think the only way for you to use poly~ beneficially, is if there are duplicate audio processes in your patch which could be encapsulated/abstraction-ized and then loaded into a poly~.  Then you could try playing around with the mute, threadcount etc.. options.


Thank you very much for the enlightening.

Maybe an interesting thing to mention is that the patch needs 35%(!) of CPU in idle state (doing nothing except having audio turned on).

Wich i think is quite a lot if you didn't wrote try to rewrite Pro Tools in MaxMSP.

The difference in CPU between Max and Live is probably that without using [poly~] Max is only using one core (or actually, someone correct me if I am wrong, but I thought you could potentially use 3 cores without [poly~], i.e. a DSP thread, a low priority message thread, and a high priority message thread. Is that right?) and that Live it automatically dealing with multicore support).

Considering your original patch is not using [poly~], your really aren't running out of CPU that fast. While you may be at only 40% overall from the OS X perspective, MSP only has access to half of that when you are using one core. If DSP Status said 40%, glitches would be surprising, but you are actually at 100% until you use [poly~]. I have experienced DSP glitches even at around 85%. Keep in mind that you will run into glitches before 100% because Max can never use 100% of your processor because OS X in the background, some external hardware, and the other software you are running will all cut your available CPU. One of the reasons I switched to an RME Mutliface II for live performance. I haven't done a test myself yet, but I have been told by someone I studied with who has, that he was able to safely use 7% more CPU by not needing to waste CPU on running the firewire bus.

I know all the "you need [poly~]" statements are probably redundant compared to the other posts, but thought having them inline would make the post more clear.

nit wrote on Sun, 30 August 2009 06:57the strange thing is that MSP starts clipping when it crosses 40% of CPU usage (according to Max's DSP CPU monitoring).
In programs like Ableton Live this clicking starts when you cross 80%.
Why does this happen so fast in MaxMSP and what can i do (besides raising the IO buffer-size, it is set to 256 wich should be more then ok).

The difference in CPU between Max and Live is probably that without using [poly~] Max is only using one core (or actually, someone correct me if I am wrong, but I thought you could potentially use 3 cores without [poly~], i.e. a DSP thread, a low priority message thread, and a high priority message thread.  Is that right?) and that Live it automatically dealing with multicore support).

Considering your original patch is not using [poly~], your really aren't running out of CPU that fast. While you may be at only 40% overall from the OS X perspective, MSP only has access to half of that when you are using one core.  If DSP Status said 40%, glitches would be surprising, but you are actually at 100% until you use [poly~].  I have experienced DSP glitches even at around 85%.  Keep in mind that you will run into glitches before 100% because Max can never use 100% of your processor because OS X in the background, some external hardware, and the other software you are running will all cut your available CPU. One of the reasons I switched to an RME Mutliface II for live performance.  I haven't done a test myself yet, but I have been told by someone I studied with who has, that he was able to safely use 7% more CPU by not needing to waste CPU on running the firewire bus.

I know all the "you need [poly~]" statements are probably redundant compared to the other posts, but thought having them inline would make the post more clear.


I will have to look how i can design my patch so i can use poly but there aren't many processes wich run the same process unfortunately.

At the moment I have quite a few performances in a row so it won't be until next month until i can post the things i'll find out but i will.

Thanks for explaining.
I will have to look how i can design my patch so i can use poly but there aren't many processes wich run the same process unfortunately.
At the moment I have quite a few performances in a row so it won't be until next month until i can post the things i'll find out but i will.


Here is a very stupid way to use both processors on a core 2 duo. Make a copy your max application. Send audio between them using soundflower or something and control data using osc and udpsend/receive to the localhost. Each instance of max will use a different processor. Depending on what you are doing this can work, but there is latency involved, of course.

MSP starts clipping when DSP CPU usage crosses 40%.