Since last week I have my own Linux 64 bit machine. One of the first issues with Pd-extended on this machine was a strongly increased CPU load when audio input is temporarily shut off from parts of my patch. Subnormals! After three hours of puzzling I identified at least one offender: [cyclone/svf~].
Sorry that most of my posts to this list seem to be about subnormals. That's quite boring. But they're seriously hogging my CPU time like a swarm of grasshoppers. As I got this 64 bit machine so recently I don't know if the issue with [cyclone/svf~] exists in earlier Pd-E versions. Also, I can not understand why it happens, because the object is protected against subnormals with function PD_BIGORSMALL(). This works well on all my other systems. Moreover, it works well for other feedback delay objects like [lop~] on Linux 64 bit. I'd like to know if anyone can confirm the issue. I was planning to do my own state variable filter anyway, but it would be nice to have a working [cyclone/svf~] as well. Check the object with attached patch if you can. To be specific, I have the issue with Pd-E 0.43.4 for Debian Squeeze amd64 from nightly builds. The i386 build is not affected. Katja
#N canvas 127 299 620 382 10; #X symbolatom 18 351 72 0 0 0 - - -; #X obj 18 323 makefilename %.70f; #N canvas 0 50 190 245 nan 0; #X obj 45 17 inlet; #X obj 46 173 outlet; #X obj 45 74 t b f; #X msg 46 96 2; #X obj 46 143 * 0; #X obj 46 118 pow 1024; #X msg 45 49 1024; #X connect 0 0 6 0; #X connect 2 0 3 0; #X connect 2 1 5 1; #X connect 3 0 5 0; #X connect 4 0 1 0; #X connect 5 0 4 0; #X connect 6 0 2 0; #X restore 18 44 pd nan; #X obj 18 20 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #N canvas 0 50 168 259 inf 0; #X obj 45 17 inlet; #X obj 46 173 outlet; #X obj 45 74 t b f; #X msg 46 96 2; #X obj 46 118 pow 1024; #X msg 45 49 1024; #X connect 0 0 5 0; #X connect 2 0 3 0; #X connect 2 1 4 1; #X connect 3 0 4 0; #X connect 4 0 1 0; #X connect 5 0 2 0; #X restore 71 44 pd inf; #X obj 71 20 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X floatatom 18 181 8 0 0 0 - - -; #X msg 72 114 1; #X msg 72 84 0; #X msg 113 108 \; pd dsp 1; #X msg 113 147 \; pd dsp 0; #X obj 113 85 loadbang; #N canvas 0 50 200 224 unsig~ 0; #X obj 32 40 inlet~; #X obj 32 122 snapshot~; #X obj 61 89 metro 200; #X obj 61 62 tgl 15 1 empty empty empty 17 7 0 10 -262144 -1 -1 1 1 ; #X obj 32 153 outlet; #X connect 0 0 1 0; #X connect 1 0 4 0; #X connect 2 0 1 0; #X connect 3 0 2 0; #X restore 18 266 pd unsig~; #X floatatom 18 296 17 0 0 0 - - -; #X text 183 133 Small floats which can't be expressed with the bits of the datatype are also denormal \, more specifically: subnormal. Computations with subnormal numbers are still possible \, but very CPU intensive. Test: click 1 first \, then 0 to see how small the numbers become. If all is OK \, numbers smaller than ~1e-19 are flushed to zero. If not OK \, numbers smaller than 1e-39 are seen. These are subnormals. Check CPU load difference. It is always possible to recover from subnormals by sending a normal number (like 1) in.; #X text 184 320 Katja Vetter Jan 2013; #X text 183 18 NaN and inf are denormal numbers. When inf or nan starts recirculating in a feedback delay line \, the object can't do further calculations \, even if the input goes back to normal. Therefore Pd must avoid writing nan or inf into a feedback delay line. Test: click nan or inf first \, and 1 thereafter. If all is OK \, the output returns to normal. If not OK \, inf or nan will stay at the output and the patch must be reloaded to recover.; #X obj 18 229 svf~ 1; #N canvas 311 334 476 347 lop 0; #N canvas 0 50 190 245 nan 0; #X obj 45 17 inlet; #X obj 46 173 outlet; #X obj 45 74 t b f; #X msg 46 96 2; #X obj 46 143 * 0; #X obj 46 118 pow 1024; #X msg 45 49 1024; #X connect 0 0 6 0; #X connect 2 0 3 0; #X connect 2 1 5 1; #X connect 3 0 5 0; #X connect 4 0 1 0; #X connect 5 0 4 0; #X connect 6 0 2 0; #X restore 28 54 pd nan; #X obj 28 30 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #N canvas 0 50 168 259 inf 0; #X obj 45 17 inlet; #X obj 46 173 outlet; #X obj 45 74 t b f; #X msg 46 96 2; #X obj 46 118 pow 1024; #X msg 45 49 1024; #X connect 0 0 5 0; #X connect 2 0 3 0; #X connect 2 1 4 1; #X connect 3 0 4 0; #X connect 4 0 1 0; #X connect 5 0 2 0; #X restore 81 54 pd inf; #X obj 81 30 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X floatatom 28 191 8 0 0 0 - - -; #X msg 82 124 1; #X msg 82 94 0; #N canvas 0 50 200 224 unsig~ 0; #X obj 32 40 inlet~; #X obj 32 122 snapshot~; #X obj 61 89 metro 200; #X obj 61 62 tgl 15 1 empty empty empty 17 7 0 10 -262144 -1 -1 1 1 ; #X obj 32 153 outlet; #X connect 0 0 1 0; #X connect 1 0 4 0; #X connect 2 0 1 0; #X connect 3 0 2 0; #X restore 28 276 pd unsig~; #X floatatom 28 306 17 0 0 0 - - -; #X obj 82 215 hsl 100 15 0 200 0 0 empty empty empty -2 -8 0 10 -262144 -1 -1 2800 0; #X floatatom 92 240 5 0 0 0 - - -; #X obj 28 239 lop~; #X text 167 27 [lop~] is also protected with PD_BIGORSMALL().; #X connect 0 0 4 0; #X connect 1 0 0 0; #X connect 2 0 4 0; #X connect 3 0 2 0; #X connect 4 0 11 0; #X connect 5 0 4 0; #X connect 6 0 4 0; #X connect 7 0 8 0; #X connect 9 0 10 0; #X connect 9 0 11 1; #X connect 11 0 7 0; #X restore 466 312 pd lop; #X text 183 261 IIR filters have internal feedback delay lines \, therefore objects like [lop~] \, [hip~] and [biquad~] must be protected against denormals. This is regularly done with macro or function PD_BIGORSMALL(). ; #X connect 1 0 0 0; #X connect 2 0 6 0; #X connect 3 0 2 0; #X connect 4 0 6 0; #X connect 5 0 4 0; #X connect 6 0 17 0; #X connect 7 0 6 0; #X connect 8 0 6 0; #X connect 11 0 9 0; #X connect 12 0 13 0; #X connect 13 0 1 0; #X connect 17 0 12 0;
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
