Subject: [linux-audio-dev] Re: [linux-audio-user] virtual sampler
From: Peter Hanappe (peter_AT_hanappe.com)
Date: Thu Feb 28 2002 - 23:54:43 EET
Hi Juan,
Excuse to reply to several mails at once, and moving this discussion
from the LAU to the LAD mailing list.
On Fri, 2002-03-22 at 01:43, Juan Linietsky wrote:
>
> 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
>
> sample_offset+=0.1;
>
> 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.
>
> ... [jumping to other mail] ...
> I made this point because iiwusynth uses float
> iterators ...
iiwusynth uses what you're describing. the iiwusynth uses 64bits fixed
point arithmetic for the phase (or sample offset as you call it). the
main reason why i changed from float to fixed point for the phase is not
speed (although the fixed point clearly is faster) but accuracy. 32bits
float wasn't accurate enough to code small phase increment. this caused
detuning and even two adjacent keys on the keyboard to be played at the
same pitch.
however, the dsp is still in float. your mails made me curious to do
some part of it in fixed point (sample interpolation and resonant
filter) before converting to float for the reverb.
> ... [yet another mail jump] ...
> After giving up on my search i've decided that i'm going to do one
> myself, so I'm working on it at the moment, using the engine of
> cheesetracker as a base, with a lot of enhacements. The priority is
> speed (polyphony) and cheesetracker can manage around 200 (or way
> more) simultaneous channels on my duron 800. It uses filtered, volume
> ramped mixers with send buffers for effects.
>
> I hope it will be usable sometime next month, since i dont have much
> time to work on it.
instead of writing a new one i'd love to take a look if we could combine
a tracker with the iiwusynth. initially, iiwusynth went for speed too
but i want to make sure it can offer professional quality sound.
if you take a look at the iiwusynth api, you'll see it'd be quite easy
to integrate it into a tracker. maybe we can do this together?
Josh Green, who developed Smurf, and i are working on integrating our
two apps. it will give a nice environment to work with wave synthesis
and to edit and play with samples dynamicly. so combining this with a
tracker be nice.
regards,
Peter
>
>
> regards
>
> Juan Linietsky
>
>
>
>
This archive was generated by hypermail 2b28 : Sun Mar 24 2002 - 21:11:41 EET