Subject: Re: [linux-audio-user] virtual sampler
From: Juan Linietsky (coding_AT_reduz.com.ar)
Date: Fri Mar 22 2002 - 02:43:46 EET
On Fri, 22 Mar 2002 01:51:55 +0200
"xk" <xk_AT_myrealbox.com> wrote:
> > Actually, I think floats offer less precision than fixed point math.
> > if you think about it, a float has only 23 bits for a real value while
> > fixed point uses the full 32 ones. This is because the kind of increment
> range (1/frequency) is known and can be easily controlled (unlike other
> applications where fixed point can be really annoying) . Natively, the fpu
> is also slower than than working with integer math. And this is in any
> architecture that i can think of. MMX helps a lot for moving the data around
> and calculating in 64bits without the worry of some overflow.
> > And with the upcoming of 64bits systems, i see using fixed point even more
> worth it.
> From what I know float multiplies at least 3 times that integer multiply
> since the days of good old Pentium I.
ok, lets get to my point, i'm basically talking about mixer speed, but seems that my point was "changed" along this thread. What i'm talking about is that VOICE MIXERS (aka, the critical zone of any synth -oscilator or wavetable based-). _that_ is what it should be written
using fixed point since it is what it uses the least CPU.
in MIDI, and usually, any kind of wavetable synthesis, the mixing consists of:
1-find nearer(s) val
-simply done with a right shift
-ONLY multiply, division is made by shifting
-yet again, only multiply, and then shift
4-mix into left/right buffers - only multiply
5-increment sample iterator
this IS slower using floats, I did made sure of that myself, i've written
mixers in both fixed point and floating point, and the SAME MIXER using fixed point WAS FASTER in machines ranging from old pentiums to
P-III and Athlons.
Where i'd like floating point better is for post processing of the channel
which is much less critical than the per-voice mixing, and for issues such as reverb.
> 23 bits is more than enough precision for digital audio, so this is not an
Allow me to prove you wrong, lets say we've got 23 bits, now.. 23 bits means numbers ranging from 0->8388608.
now let's say we have a sample iterator, in other words the offset to a sample being played. in each sample mixed, we must do step 5 of what i have described above, this is:
sample_offset+=increment; (we take the integer part only to find the current sample but we need the decimal part to have an accurate increment)
Lets say, we're mixing in a buffer at 44.000hz, a sample at 44hz, which happens to have 2pi (a cycle) every 100 samples.
now, lets see what the increment should be per sample, this should be: 0.1 , this means, every sample we do
so, here's the problem, once we get to sample 838860.8 , the iterator
will stop being able to add more, and your sample will die there.
this is, in this example, you cant read a sample bigger than 800k
Thats why, when you use floats, some people uses two floats, one for decimal increment and one for integer, but it still sucks! because you _cant go over samples > 8MB_
This is why floats basically suck for sample mixing and they shouldnt be used. Using fixed point you can decide how much goes for decimal or integer, or even use ADC with a 64bits integer when you work with increments.
> And with floats you don't have to wory about overflows and you can finally
> exceed clipping range in a chain of plugins and just put a limiter at the
> end. This is a real time saver.
but as i said before, your floats can get stuck and cause you a lot of problems.
This archive was generated by hypermail 2b28 : Fri Mar 22 2002 - 02:29:46 EET