Stewart H

I'm currently writing an external in C that does some things with single-sample feedback loops.

The patcher is currently working fine; it's reasonably CPU-intensive - the DSP status window reports it as using a fairly constant 15% CPU.

Now here's the interesting part. If I hit Ctrl-S while audio processing is turned on, the external stops producing any output. Other audio still continues - as tested by sending a cycle~ to DAC. When the external breaks in this fashion, if I watch the CPU meter in Max/MSP, the CPU usage jumps up to around 50-60%, with occasional peaks at 80-100%. Now even stranger - if I send my extnernal a message to clear the feedback delay memory, the CPU usage drops down again to 15%, the audio comes back, and everything works again.

strange-behaviour-causes-externals-to-stop

Hard to divine without seeing some code... how are you running your 

inner (single-sample) loop? I hope there are no Max API calls in 

The CPU indication looks like denormals, a common issue with feedback 

In short, a side-effect of the CPU architecture is that numbers 

incredibly close to zero cause the CPU to go into a hissy fit.

https://cycling74.com/twiki/bin/view/FAQs/

WindowsMaxMSP#What_is_the_denormal_problem_and

But the easy way is to make use of existing code in the MaxAudioAPI 

#define FIX_DENORM_FLOAT(v)        ((v)=IS_DENORM_FLOAT(v)?0.f:(v))

Wherever your feedback is, wrap it with FIX_DENORM_FLOAT(); that 

Though I have no idea why Ctrl-S would have anything to do with it... 

would need to know more about your algorithm/usage.

On Oct 13, 2008, at 6:53 AM, StewartH wrote:

> I'm currently writing an external in C that does some things with 

> The patcher is currently working fine; it's reasonably CPU- 

> intensive - the DSP status window reports it as using a fairly 

> Now here's the interesting part. If I hit Ctrl-S while audio 

> processing is turned on, the external stops producing any output. 

> Other audio still continues - as tested by sending a cycle~ to DAC. 

> When the external breaks in this fashion, if I watch the CPU meter 

> in Max/MSP, the CPU usage jumps up to around 50-60%, with 

> occasional peaks at 80-100%. Now even stranger - if I send my 

> extnernal a message to clear the feedback delay memory, the CPU 

> usage drops down again to 15%, the audio comes back, and everything 

Hard to divine without seeing some code... how are you running your  
inner (single-sample) loop? I hope there are no Max API calls in  
there...

The CPU indication looks like denormals, a common issue with feedback  
loops on certain x86 processors:
http://en.wikipedia.org/wiki/Denormal

In short, a side-effect of the CPU architecture is that numbers  
incredibly close to zero cause the CPU to go into a hissy fit.

see also: https://cycling74.com/twiki/bin/view/FAQs/ 
WindowsMaxMSP#What_is_the_denormal_problem_and

Here's a great summary of solutions: http://www.musicdsp.org/files/ 
denormal.pdf

But the easy way is to make use of existing code in the MaxAudioAPI  
(z_dsp.h):

#define FIX_DENORM_FLOAT(v)		((v)=IS_DENORM_FLOAT(v)?0.f:(v))

Wherever your feedback is, wrap it with FIX_DENORM_FLOAT(); that  
might just solve the problem.

Though I have no idea why Ctrl-S would have anything to do with it...  
would need to know more about your algorithm/usage.

>
> Hi everybody,
>
> I'm currently writing an external in C that does some things with  
> single-sample feedback loops.
>
> The patcher is currently working fine; it's reasonably CPU- 
> intensive - the DSP status window reports it as using a fairly  
> constant 15% CPU.
>
> Now here's the interesting part. If I hit Ctrl-S while audio  
> processing is turned on, the external stops producing any output.  
> Other audio still continues - as tested by sending a cycle~ to DAC.  
> When the external breaks in this fashion, if I watch the CPU meter  
> in Max/MSP, the CPU usage jumps up to around 50-60%, with  
> occasional peaks at 80-100%. Now even stranger - if I send my  
> extnernal a message to clear the feedback delay memory, the CPU  
> usage drops down again to 15%, the audio comes back, and everything  
> works again.
>
> Thanks,
> Stewart

Strange behaviour causes externals to stop?