[PD-dev] preparing phasor~&Co. for double precision Pd

[katja]

Hello,

Triggered by a recent thread (
http://lists.puredata.info/pipermail/pd-dev/2011-07/017022.html) I've
written alternative code for Pd classes like phasor~, osc~, and vcf~, in
preparation for double precision builds of Pd. These classes currently
employ Hoeldrich's method, a fascinating type punning trick for optimization
of phase-wrapping jobs. Considering available data types in C, this method
can not be translated to double precision input/output format.

Phasor~ and osc~ are typically used by the dozens in Pd setups, and even a
modest performance loss could be a show stopper for setups which are on the
limit of acceptable CPU load. Fortunately it was possible to define
double-ready versions without performance loss, by tedious elimination of
redundancy instead of fancy bit hacking. How often must a phase be wrapped?
Even at high frequencies like half the Nyquist rate, only one in four
iterations goes out of bounds. On average it proves efficient to do the
phase wrapping conditionally. Phasor~ profits most, being up to three times
faster than before, at moderate frequencies. The others did not speed up so
much, but at least none of them is slower than the original version, when
both are compared within the same Pd build. Also, the alternative versions
do not suffer from phase drift, like the Hoeldrich versions do. I have
tested this on OSX / IntelMac for single and double precision builds.
Performance may be different on other platforms / architectures. Macro
PD_BIGORSMALL was redefined to work with arbitrary precision.

A Pd running with PD_FLOATTYPE double immediately shouted at me that there's
a lot more work to do. The audio API (PortAudio in this case) couldn't
handle 64 bit output samples from dac~. Vectors are apparently read as type
float, and maximum level digital noise is the useless output. I've not
delved into this yet. Internally things seems to work well, for what I've
seen so far.

Ah, almost forgot to mention the pro's of a double precision Pd, if it will
ever work:

- indexing of large audio buffers with ample resolution for interpolation
- accurate sine and sinc of small angles, useful for things like fractional
delay
- FFT with frames larger than 2^17, I hope
- long sine sweeps without artifacts
- probably many more of such meticulous dsp jobs, you name them

If you're interested in double precision Pd, please find the attached
pd_doubletest.zip with C code and test-patches. Let me know if you have test
results on different platforms, or if you find stupid bugs in my code. Is
anyone working on other aspects of double precision Pd? I'd like to join
forces.

Katja Vetter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20110727/5c34c628/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pd_doubletest.zip
Type: application/zip
Size: 30102 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20110727/5c34c628/attachment-0001.zip>