Subject: [linux-audio-dev] EVO 0.0.5 released , resampling (interpolation) support added
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Tue Sep 19 2000 - 17:26:59 EEST
Hi,
I added resampling capabilities to EVO. (magically got rid of this PITA :-) )
Fefault is linear interpolation, but you can switch to hermite, by commenting
out the USE_LINEAR_INTERPOLATION in audiovoice.cpp )
get the code here:
http://www.linuxdj.com/evo/evo-0.0.5.tar.gz
I scratched my head for the entire last week about how to implement this
efficiently, because we are interpolating from segmented memory areas rather
than from linear segments, where it is much easier to look behind and ahead of
the current playback position)
Since the plan is to use Olli's (patented TM^2 :-) ) parameter sloping to
achieve smooth and efficient (from CPU POV) filter sweepings,
volume, pitch (and other params) rampings, I had to find a solution for the
preloading of samples which works in every situation
(eg when the pitch is increasing sharply during a single fragment)
Of course low CPU usage is one of the highest priorities.
And I think I've found a quite efficient solution, which delivers performance
which is almost at par as interpolating from linear memory segments:
basically what I am doing is preloading some extra samples in the initial part
so that the interpolation code can cross the buffer boundary while still finding
the right data.
And the streambuffers are increated in size a bit too, and have now a check
when the buf pointer gets near the end, some samples from the beginning of the
buffer (which is the continuation of the end), are copied past the buffer end,
so that the interpolation code can happily cross the border finding the right
data. The memcpy() is done only every 128K samples, which means almost
zero added overhead.
One drawback (Olli, listen ! :-) ) is that in the case of higher order
interpolation (eg hermite, 3rd order), I do not look 1 sample behind and 2
ahead as in Olli's code, but 3 ahead (because looking behind is a PITA), that
means the output is delayed by one sample, but that's not an issue since
all voices are delayed by this sample, and one sample is about 22usec delay,
which means zero compared to a few msec latency.
I'd like to hear some comments about the algorithm,
if it looks ok to you or if you have better solution in sight.
(relevant code: audiovoice.cpp render_audio_ram() and render_audio_disk(),
and ringbuffer.h check_wrap() )
Currently the code simply uses the resampling code to allow pitchbending
of +/-12 semitones, but the engine is fully ready to accomodate multisampled
instruments with arbitrary keyzones (eg 1-2 samples for octave or so),
you are not longer forced to provide a sample for every key.
and send feedback (on the list please)
PS: thank's to Intels DISASTROUS floatint point to int conversion
(read the music-dsp archives for the reason of this),
EVO uses an indecent amount of CPU because
a simple pos_int=(int)pos; (pos is a double).
I did not believe it when I saw it:
36 voices without the (int) statement: about 22% CPU usage, which
is quite good.
with the (int) statement (which is needed to calculate the
int and fract part of the pos in the case of interpolation),
a CPU usage of 50% was measured !!
The solution lies in using some assembly code, which would
bring the performance back to the 22-25% CPU usage.
(basically what is slowing down the fp->int conversion is
setting the FPU back and forth from rounding to truncate mode
and viceversa)
And that's why I am now trying to learn some x86 assembly,
and bitching around about WHY Intel engineers developed
this silly FPU register stack model :-)
(Any x86 assembly experts out here ?)
PS2: I disabled envelopes for now because the goal is to include
Olli's even proposal (read our IRC logs :-)), and this is not that trivial
to do. (because you have to intermix scheduled (eg volume ramps),
with realtime events (note-off events which have to change the volume
envelopes on the fly without causing collisions with the scheduled events,
basically another PITA :-) )
happy streaming :-)
cheers,
Benno.
This archive was generated by hypermail 2b28 : Tue Sep 19 2000 - 17:16:46 EEST