A useful debug trick, to make sure denornals are the problem, is to inject a wee bit of noise into the path and see if it speeds up. My experiences of them in the past is that they take a while st show up, maybe many seconds or even minutes after the patch seems silent (rather than being present under quiescent conditions).
On Fri, 31 Oct 2008 16:27:08 -0400 Bill Gribble <[EMAIL PROTECTED]> wrote: > I have a patch of medium complexity, with a handful of instruments~ and > a bunch of sequencing and arranging-type message handling. On my speedy > Intel laptop it has no problem and barely notches the CPU usage. > However, when I run this patch on my teeny Geode-based UMPC it pegs CPU > at 100%. > > I'm pretty sure this is a denormal issue. There are a grand total of > maybe 5 noise~, 5 osc~, 10 vline~, 5 lop~, and 1 delay line in the whole > patch and not much else besides message processing... I wouldn't guess > this to run me out of compute power. > > Any hints on how to isolate where the denormals might be popping up? I > have looked for signal processing loops, and the only ones I create are > around the delayline (feedback) and I suppose in the iir implementation > of the lop~. > > Any help appreciated, > Bill Gribble > > > > > > > > > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list -- Use the source _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
