17 Oct
2003
17 Oct
'03
2:50 p.m.
On Friday 17 October 2003 12:20, Paul Davis wrote:
if you're writing software where you do this conversion more than once
per interrupt, i think it probably needs a redesign. if the cost of
the conversion is an appreciable fraction of the over
cycles/interrupt, then and only then does it seem to make sense to me
to consider *not* using float.
--p
This is the case of a resampler in a polyphonic sampler (and other algorithms
such as multivoiced chorus and time domain pitchshifters), or synthesizers
wich relies on prerendered oscillators. it ocurs N times per interrupt, being
N the amount of voices active. A resampler needs a fractional increment which
is calculated according to the voice pitch.
When you need to get the actual sample position (and/or the surrounding
ones if you are interpolating), a fractional -> integer conversion is needed.
I've seen this problem happening on existing software, which greatly limits
the CPU availability. Some examples of this are fluidsynth, csound and
zynaddsubfx. If you compare them with software of this kind written
in fixed point (cheesetracker, legasynth, timidity), the later can easily
reach many times more the amount of virtual voices.
I have to add something in here, besides the float->int conversion,
there is another very common source of slowdowns in this kind of
software, which is using conditions inside the critical loops. These,
at minimum, will flush the processor pipeline (And I think something else
too but I coudlnt tell) until decoded.
Juan Linietsky