>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 do remember some nice benchmark-like work done on this list using a small oscillator program that showed how much faster it was to store the phase in a fixed point representation. the difference was huge - quite a remarkable demonstration of the poor design of the x86, because on other processors (notably the MIPS), there was essentially no difference. but i think this is really totally different from the question of float/int sample format. its forced by the need for an integer to act as an array offset, and the heavy cost of the float<->int conversion. you should still use float samples, unless you can show that the cost of the conversion in and out overwhelms everything else. JACK's API merely adds to the reasons for doing this (e.g. the hassle i had converting the soundtouch library to use float instead of short). --p