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 grib@billgribble.com 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