Dear list, while the basic port of pd for the gluiph's TriMedia port went rather painlessly (compared to the hardware dev anyway...), there's still a few details that need to be ironed out. One I'd like to have your opinion/experience on is double precision arithmetic, which I'd have to run thru a software lib that slows things down by a factor of 100. Browsing thru the pd source, double precision seems to be used mainly (1) to process phase information for the oscillators (2) for system timing and (3) misc. graphic stuff.
(3) is not much of a problem since the GUI will be stripped anyway (2) is not called all too often (?), so the slow down is kinda acceptable (1) is what I'd like your opinion on - how much do double precision phases improve sound quality ? (btw it seems that e.g. phasor~ doesn't use most of those extras bits but wraps around at 32 bits... can this be confirmed ??)
second question is what people use for benchmarking, as I'm curious to see how my little box stacks up against the heavyweights. Preferably something w/o sound file access, as the file system is one of those other details I still have to tweak...
thanks much, Sukandar
Hi all,
I think 32 bit precision is enough for most uses you would put an oscillator to. The reason Pd uses double is so that the mantissa can have at least the 32 fractional bits plus another 8 bits of "headroom" so that the floating point adder won't shift the phase as it accumulates.
For hardware platforms which don't have hardware double precision arithmetic, it's probably better to keep phase as a 32-bit fixed-point fraction. I think the oscillator in csound works like this and could be used in place of Pd's oscillator code (same for phasor~, cos~, and friends.)
However, signgle-precision floating point phase probably won't work well...
cheers Miller
On Sun, Mar 24, 2002 at 03:41:54AM +0100, Sukandar Kartadinata wrote:
Dear list, while the basic port of pd for the gluiph's TriMedia port went rather painlessly (compared to the hardware dev anyway...), there's still a few details that need to be ironed out. One I'd like to have your opinion/experience on is double precision arithmetic, which I'd have to run thru a software lib that slows things down by a factor of 100. Browsing thru the pd source, double precision seems to be used mainly (1) to process phase information for the oscillators (2) for system timing and (3) misc. graphic stuff.
(3) is not much of a problem since the GUI will be stripped anyway (2) is not called all too often (?), so the slow down is kinda acceptable (1) is what I'd like your opinion on - how much do double precision phases improve sound quality ? (btw it seems that e.g. phasor~ doesn't use most of those extras bits but wraps around at 32 bits... can this be confirmed ??)
second question is what people use for benchmarking, as I'm curious to see how my little box stacks up against the heavyweights. Preferably something w/o sound file access, as the file system is one of those other details I still have to tweak...
thanks much, Sukandar --
__--__--__-___-_--_-_-___-_-_--___-_-___ sukandar kartadinata the glui performance hardware http://www.glui.de/proj/gluiph.html _--__---_--_--___---_-_-_--_-__-
I wrote:
Browsing thru the pd source, double precision seems to be used mainly (1) to process phase information for the oscillators (2) for system timing and (3) misc. graphic stuff.
(3) is not much of a problem since the GUI will be stripped anyway (2) is not called all too often (?), so the slow down is kinda acceptable
after more analysis it seems that functions like sys_getrealtime() are called more often than I assumed (or is it just my simple test patches spending too much time int the idle loop ?). So I have to ask again: could a float variable be sufficient for the timing stuff maybe ? Or what's the best way to tackle this ? (fwiw, I have access to a 64bit cycle counter, so the precision is available)
oh, and the 32bit integer version of phasor~ sounds quite alright. Thanks for the suggestion. (Couldn't find it in CSound though)
cheers Sukandar
On Thu, 28 Mar 2002, Sukandar Kartadinata wrote:
oh, and the 32bit integer version of phasor~ sounds quite alright. Thanks for the suggestion. (Couldn't find it in CSound though)
Where do you have it from ?
Regarding the timer and stuff, I have a fixed point pd version for the iPaq, which is halfway done, I would be happy if we could team up. There are some oscillators there already, the timer stuff is done in integer, the last time I touched it was when I was porting the fft stuff, I must have gotten something very wrong because fft/ifft sounds horrible :)
Guenter
__--__--__-___-_--_-_-___-_-_--___-_-___ sukandar kartadinata the glui performance hardware http://www.glui.de/proj/gluiph.html _--__---_--_--___---_-_-_--_-__-
oh, and the 32bit integer version of phasor~ sounds quite alright. Thanks for the suggestion. (Couldn't find it in CSound though)
Where do you have it from ?
oh, just did some quick (dirty) coding myself not much to do for a phasor than some simple accumulating and only slightly more difficult for the other oscillators (and a good excercise in dsp, after all that system design in the past years)
Regarding the timer and stuff, I have a fixed point pd version for the iPaq, which is halfway done, I would be happy if we could team up.
I'd be happy to exchange ideas where possible ! However, I think our general goals are slightly different as I try to stay as close to the original distribution as possible, while I assume that you have spawned off quite far with your pure integer implementation, no? So I guess we couldn't even exchange oscillators. (could send you the code though if you're interested)
But for the timers I'd be curious how you handled this. Do you reduce the timing precision with a single 32bit int ? Or use two of them ? But then this would require much more changes to the code (operator overloading would come handy here...). Maybe not a problem for you if you're rewriting most of the code anyway. Anyway I decided to stick with double for now as it's working OK and there are more important issues to solve. Maybe I'll try something with a forced fixed point representation (like the original phasor~ code), so I can keep double for the calling files, and restrict the code changes (some simplified double arithmetic) to m_sched.c and s_unix.c
Q: would it be possible to define timing variables/functions with something like t_systime instead of double ? That would make certain things easier... (also, I'm kinda confused about the mixed use of float and t_float - is there a scheme behind this ? And while I'm at it: why is printing and error reporting encapsulated in s_print.c but still many fprintf commands etc. in other files ? (if this just needs some spring cleaning I'd volunteer....:))
best, Sukandar
On Tue, 2 Apr 2002, Sukandar Kartadinata wrote:
oh, and the 32bit integer version of phasor~ sounds quite alright. Thanks for the suggestion. (Couldn't find it in CSound though)
Where do you have it from ?
oh, just did some quick (dirty) coding myself not much to do for a phasor than some simple accumulating and only slightly more difficult for the other oscillators (and a good excercise in dsp, after all that system design in the past years)
Regarding the timer and stuff, I have a fixed point pd version for the iPaq, which is halfway done, I would be happy if we could team up.
I'd be happy to exchange ideas where possible ! However, I think our general goals are slightly different as I try to stay as close to the original distribution as possible, while I assume that you have spawned off quite far with your pure integer implementation, no?
Yes, right, originally I wanted to stay close to the original, but it prooved to be to much hassle to do so, at the end the iPaq has other limitations too, not only floating point but screen size, fonts etc. ...
So I guess we couldn't even exchange oscillators. (could send you the code though if you're interested)
But for the timers I'd be curious how you handled this. Do you reduce the timing precision with a single 32bit int ? Or use two of them ? But then this would require much more changes to the code (operator overloading would come handy here...). Maybe not a problem for you if you're rewriting most of the code anyway.
Well, I just replaced the time stuff int the scheduler loop and sys_getrelatime() to int. So I left the clock_ functions the way they are, at least something I have tio think about yet.
Anyway I decided to stick with double for now as it's working OK and there are more important issues to solve. Maybe I'll try something with a forced fixed point representation (like the original phasor~ code), so I can keep double for the calling files, and restrict the code changes (some simplified double arithmetic) to m_sched.c and s_unix.c
If I understood you right, your problem isn't floating point in general but double precision ? The scheduler loop for the arm processor eats up 40 % of the CPU when using a double counter ...
Q: would it be possible to define timing variables/functions with something like t_systime instead of double ? That would make certain things easier... (also, I'm kinda confused about the mixed use of float and t_float - is there a scheme behind this ? And while I'm at it: why is printing and error reporting encapsulated in s_print.c but still many fprintf commands etc. in other files ? (if this just needs some spring cleaning I'd volunteer....:))
the float and t_float issues definitely need cleanup. but thats not all there is t_sample (which is the sample type, defaults to float). There is t_float, which is used for floating point messages more or less, and there is t_floatarg, which is the type of floating point numbers passed internally for pd functions.
What can be seen by this setup is that, once cleaned up, it should theoretically be easy toswitch from float to double precision within computations. (Well not for the "magic" oscillators implementation).
Finally, a timer type would help my efforts of beeing able to choose between types for the timer..
Greetings,
Guenter
-
g�nter geiger -
Miller Puckette -
Sukandar Kartadinata