It appears that current iteration of freeverb~ is susceptible to denormals bug. Namely, feeding silence after sound hogs cpu (I chuckled by reading Pd's CPU footprint which was in excess of 400%). Adding a tiniest amount of DC bias inside Pd solves this but I wonder shouldn't this be simply added to the freeverb c code instead?
Ivica Ico Bukvic, D.M.A. Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Assistant Co-Director, CCTAD CHCI, CS, and Art (by courtesy) Virginia Tech Dept. of Music - 0240 Blacksburg, VA 24061 (540) 231-6139 (540) 231-5034 (fax) ico@vt.edu http://www.music.vt.edu/faculty/bukvic/
On Sat, 14 Nov 2009, Ivica Ico Bukvic wrote:
It appears that current iteration of freeverb~ is susceptible to denormals bug. Namely, feeding silence after sound hogs cpu (I chuckled by reading Pd's CPU footprint which was in excess of 400%). Adding a tiniest amount of DC bias inside Pd solves this but I wonder shouldn't this be simply added to the freeverb c code instead?
On which CPUs does this problem occur? It seems both annoying and a good excuse to slow down programmes on CPUs that don't have the problem (?).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
It appears that current iteration of freeverb~ is susceptible to
denormals
bug. Namely, feeding silence after sound hogs cpu (I chuckled by
reading
Pd's CPU footprint which was in excess of 400%). Adding a tiniest
amount of
DC bias inside Pd solves this but I wonder shouldn't this be simply
added
to
the freeverb c code instead?
On which CPUs does this problem occur? It seems both annoying and a good excuse to slow down programmes on CPUs that don't have the problem (?).
This is on Intel Atom 1.6GHz (netbook). Freeverb~ source is from the pd-extended branch (I believe), although it could be from the 0.41.4 rather than 0.42.5 (not sure if that makes any difference).
Ico