[PD] switch~ & cputime climbing

martin.peach at sympatico.ca martin.peach at sympatico.ca
Wed Jun 6 16:44:09 CEST 2007


That looks like the old denormal problem again, where the cpu goes into some kind of exception handling when a floating point value is between zero and the next smallest full-precision float, a number like 0.000000000000000001.

Martin

> I'm not positive about this, but I think I've traced the CPU-climb to 
> the [moog~] filter.  It has an odd behavior that can be broken into 
> three phases:
> 
> 1) no audio greater than zero amplitude has passed through it yet (since 
> patch load)
> 2) audio of some amplitude >0 passes through
> 3) audio passing through goes back to zero amplitude
> 
> At 3) (or, more accurately, several seconds after), its CPU usage climbs 
> fairly dramatically, only to drop down again when the amplitude of the 
> audio goes up again.   Something in the filter model doesn't like zero 
> amplitude, but only after it's first processed something greater than zero.
> 
> I meant to test this more rigorously, but got sidetracked.  At any rate, 
> when I switch~ the [moog~] filter out, CPU usage holds steady.  To be 
> clear, I don't think this relates to [switch~].  I'm on a Macbook Pro, 
> currently running 0.39rc2.
> 
> Phil
> 
> 
> 
> Derek Holzer wrote:
> > Hi Phil,
> >
> > just to keep this in people's minds... I have exact same problem 
> > described in these emails with my Particle Chamber granular synthesis 
> > patch. It has 32 "switch~ed" voices. Using one instance seems to be 
> > OK, but two or more leads to exponentially-growing CPU usage that 
> > eventually makes PD unresponsive to the GUI (and eventually would 
> > probably crash PD if I let it go on...) I guess this could relate to 
> > the "isn't the GUI supposed to have lower priority than    process?" 
> > thread, since this particular problem makes PD a bit unusable for the 
> > kind of performances I want to be doing with it. The fact that PD 
> > lacks a usable voice-allocation method (i.e. CPU resources can be 
> > allocated and de-allocated to a voice, something which switch~ has a 
> > bug with, and which Nqpoly~ and so on does not do at all) means that I 
> > must start looking into SuperCollider to work with my polyphonic 
> > granular synthesis stuff. Sad but true...
> >
> > d.
> >
> > Phil Stone wrote:
> >> Hi,
> >>
> >> I'm getting a slow-but-steady climbing CPU when running some 
> >> synthesis patches.  I (like the poster below) have sub-modules that 
> >> can be switch~ed on and off.  An archive search turned up the 
> >> following un-replied post:
> >>> Hi all
> >>>
> >>> Okay.  I'm stumped.
> >>>
> >>> Recently, I've noticed that my cpu meter has been steadily rising.  
> >>> I  think I may have found the culprit.
> >>>
> >>> A while back I thought I'd put a power switch (just a switch~ 
> >>> object)  on my poor-man's granular delay line, as my performance 
> >>> patches are  getting a bit bulky.
> >>>
> >>> Try this (if you have the time):
> >>>
> >>> http://www.sideshowmedia.ca/cputest.zip
> >>>
> >>> cputest.pd: (needs expr, but I think that's all)
> >>>
> >>> 1. turn on audio in pd, but leave the power (p toggle) in "lois"  
> >>> off.  Watch the cpu meter climb (over a period of 5 minutes or so -  
> >>> the toggle prints the cputime every 10 seconds).  On my computer 
> >>> (G4  Powerbook, HCS extended 0.38.4) it starts around 5% and hits 
> >>> 10%  after 5 minutes.
> >>>
> >>> 2. Do the same with "lois" on.  For me, cpu hovers around 13-14%.  
> >>> No  increase.
> >>>
> >>> 3. Repeat step 1.  After 10-15 minutes, cputime is higher than with  
> >>> "lois" on.  Switch "lois" on, and cpu drops.  Huh?
> >>>
> >>> I have no idea what's going on, but am I missing something  
> >>> important?  Thanks in advance.
> >>>
> >>> cheers
> >>> dafydd
> >>>   
> >>
> >> Does anybody have any insight on this?  I don't remember this 
> >> happening until fairly recently, but don't know if it dates to when I 
> >> started switch~ing modules.  I'm currently running 0.39.2-extended 
> >> RC1 on a MacBook Pro.
> >>
> >>
> >> Phil Stone
> >>
> >> _______________________________________________
> >> PD-list at iem.at mailing list
> >> UNSUBSCRIBE and account-management -> 
> >> http://lists.puredata.info/listinfo/pd-list
> >>
> >
> 
> 
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
> 





More information about the Pd-list mailing list