Thomas Resch

when I'm running my object with scheduler in audio interrupt and send a lot of messages to my object, the dsp utilization becomes more and more after a while. This is some kind of backlogging problem, ok. When I'm calling defered versions of my functions, the problem disappears, but I thought Max simply drops events if there are to many?? Or do I have to take care of this myself? Check whether scheduler is in audio interrupt and if so, call defered functions?

Weird thing is, even when I'm doing nothing anymore, only DSP is turned on, the utilization stays the same, until I delete my object.

hi everyone,
when I'm running my object with scheduler in audio interrupt and send a lot of messages to my object, the dsp utilization becomes more and more after a while. This is some kind of backlogging problem, ok. When I'm calling defered versions of my functions, the problem disappears, but I thought Max simply drops events if there are to many?? Or do I have to take care of this myself? Check whether scheduler is in audio interrupt and if so, call defered functions?

Weird thing is, even when I'm doing nothing anymore, only DSP is turned on, the utilization stays the same, until I delete my object.
Cheers,
Thomas


weird-dsp-utilization-with-scheduler-in-audio-interrupt

If you call the defer() function and the message is coming on the main thread, then method you pass to defer will be called immediately (no change). If you call the defer() function and the message is coming on the scheduler thread (with SIAI the scheduler thread is the same as the audio thread) then the function call to your method will be moved to the main thread.

So defer() is your friend here. Because timing is important for the scheduler thread, it is generally best to defer things that are expensive to the main thread if possible.

It's difficult to speculate about the cause of any backlog without the source code.

Instead of using defer() you can alternatively create a qelem and set the qelem from the method called in the scheduler thread. The qelem will be serviced in the main thread. The benefit of the qelem in this case is that you can use it to drop messages if you get flooded with more than can be serviced at a given time, thus eliminating any chance for a backlog (but possibly losing/thinning data in the process).

If you call the defer() function and the message is coming on the main thread, then method you pass to defer will be called immediately (no change).  If you call the defer() function and the message is coming on the scheduler thread (with SIAI the scheduler thread is the same as the audio thread) then the function call to your method will be moved to the main thread.

So defer() is your friend here.  Because timing is important for the scheduler thread, it is generally best to defer things that are expensive to the main thread if possible.

Instead of using defer() you can alternatively create a qelem and set the qelem from the method called in the scheduler thread.  The qelem will be serviced in the main thread.  The benefit of the qelem in this case is that you can use it to drop messages if you get flooded with more than can be serviced at a given time, thus eliminating any chance for a backlog (but possibly losing/thinning data in the process).

one question: since with SIAI the scheduler is the same as the audio thread, this means, every function which allocates memory should always be defered?

Hi @Thomas -- you are correct. Also you don't want to do expensive things (like allocate or free memory) in the scheduler thread anyway (overdrive on but SIAI off) because that will degrade the timing of the scheduler.

One option is to defer anything that needs to alloc/free/resize memory, and another option is to pre-allocate a pool of memory for your object and then simply adjust the amount of memory from that pool that you are actually using.

Hi @Thomas -- you are correct.  Also you don't want to do expensive things (like allocate or free memory) in the scheduler thread anyway (overdrive on but SIAI off) because that will degrade the timing of the scheduler.

weird dsp utilization with scheduler in audio interrupt