Carl Hetherington has a good write up on denormals: http://carlh.net/plugins/denormals.php
This is the most interesting point:
"The P3 always has problems with denormals no matter what GCC flags or CPU modes are used.".
So unless you want your program to function on a P3, you can safely compile your denormal-creating program with sse math and turn on DAZ and FTZ. You won't get any problems with denormals then.
On Mon, Feb 8, 2016 at 4:13 PM, Ivica Ico Bukvic ico@vt.edu wrote:
I thought this, too. I seem to (mis)remember somewhere that -O2 optimization at compile-time would help with this, which is what pd-l2ork's freeverb~ uses and still exhibits previously reported behavior. That said, I wonder if denormals would also solve potential NaNs. At any rate, I've updated freeverb~ to explicitly use denormal function's return value in pd-l2ork and will run some tests and let you know. If you'd like to test it out, download the latest deb dated 20160208 (64bit build only for the time being).
Best,
Ico
On 2/8/2016 4:44 AM, Kjetil Matheussen wrote:
Regarding denormals, if that's the problem, shouldn't it be good enough to compile with -fpmath=sse -msse2 and run the following code one time in the dsp thread?
#ifdef __SSE__ #ifdef __SSE2__ #define AVOIDDENORMALS _mm_setcsr(_mm_getcsr() | 0x8040) #else #define AVOIDDENORMALS _mm_setcsr(_mm_getcsr() | 0x8000) #endif #else # error "must compile with -fmpath=sse" #endif
On Mon, Feb 8, 2016 at 10:28 AM, Kjetil Matheussen < k.s.matheussen@gmail.com> wrote:
You could use the faust version of freeverb and compile it for pd. It's probably less likely to have bugs. For instance by pasting http://sourceforge.net/p/faudiostream/code/ci/master/tree/examples/freeverb.... into http://faust.grame.fr/onlinecompiler/
On Sun, Feb 7, 2016 at 4:08 AM, Ivica Bukvic < ico@vt.eduico@vt.edu> wrote:
Thank you, Katja. Is there a newer version than this out there?
Best,
-- Ivica Ico Bukvic, D.M.A. Associate Professor Computer Music ICAT Senior Fellow Director -- DISIS, L2Ork Virginia Tech School of Performing Arts – 0141 Blacksburg, VA 24061 (540) 231-6139 <%28540%29%20231-6139> ico@vt.edu www.performingarts.vt.edu disis.icat.vt.edu l2ork.icat.vt.edu ico.bukvic.net On Feb 6, 2016 10:25 AM, "katja" katjavetter@gmail.com wrote:
If the freeverb~ version you use looks like the one in
http://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/freeverb~/f... , there's a function 'fix_denorm_nan_float() defined starting at line 154. The function is called later (in line 225 and others) but the return value is never stored. Therefore freeverb~ doesn't flush denormals.
On Sat, Feb 6, 2016 at 3:34 PM, Ivica Bukvic ico@vt.edu wrote:
Thank you all. Looks like I've got some troubleshooting to do and will report what I find.
Best,
-- Ivica Ico Bukvic, D.M.A. Associate Professor Computer Music ICAT Senior Fellow Director -- DISIS, L2Ork Virginia Tech School of Performing Arts – 0141 Blacksburg, VA 24061 (540) 231-6139 <%28540%29%20231-6139> ico@vt.edu www.performingarts.vt.edu disis.icat.vt.edu l2ork.icat.vt.edu ico.bukvic.net
On Feb 6, 2016 9:20 AM, "IOhannes m zmölnig" zmoelnig@iem.at wrote:
On 02/06/2016 10:29 AM, katja wrote: > Possibly an inf or nan recirculating in the delay lines? It seems
that
> freeverb~ calls function fix_denorm_nan_float(float v) but doesn't
use
> the return value.
you *might* be able to confirm this by sending the output for [freeverb~] to [print~] (the silent samples would be NaN or Inf
rather
than 0 (or some other constant value))
gamds IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list http://lists.puredata.info/listinfo/pd-list