iiwusynth-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[iiwusynth-devel] Fw: Re: [linux-audio-dev] more about iiwusynth


From: Juan Linietsky
Subject: [iiwusynth-devel] Fw: Re: [linux-audio-dev] more about iiwusynth
Date: Thu, 6 Jun 2002 18:59:04 -0300

Hello everyone! I didnt know about this list, josh just told me about
it. My name is Juan Linietsky, i'm the author of some adio apps such
as CheeseTracker (an impulse tracker clone with some addons),
ShakeTracker ( a midi tracker) and Saturno (a fast yamaha dx/7 fm
synthethizer emulator). I've been interested in iiwusynth for a long
time as it's a great audio app, and now that swami is out I'm really
excited about using both!
Unforntunatedly, my biggest problem with Iiwusynth is the speed and
overall slowness of it (it's just _very_ slow). I've been messing with
the code and doing some tests, and found out that the source of the
slowness is the iiwu_run_dsp function, which is HIGHLY unoptimized.
I'm feeling like improving the mixer for speed by converting it fullly
to fixed point, but i'll need some forward and info about the
format/ranges of some buffers/variables. Attached is the mail i've
sent to linux-audio-dev with my thoughts about the mixer code.




----------------------------

Begin forwarded message:

Date: Thu, 6 Jun 2002 01:14:26 -0300
From: Juan Linietsky <address@hidden>
To: address@hidden
Subject: Re: [linux-audio-dev] more about iiwusynth


On 05 Jun 2002 20:11:55 -0600
Josh Green <address@hidden> wrote:

> On Wed, 2002-06-05 at 17:11, Juan Linietsky wrote:
> > On 05 Jun 2002 05:09:17 -0600
> > Josh Green <address@hidden> wrote:
> > 
> > > To LAD list members:
> > > I'm aware that there is a new Linux Audio Announce list, but I
> > > thought that since this is an initial release announcement, all
> > > would be forgiven :)
> > > 
> > > Swami 0.9.0pre1 has been released. Swami is the new name of the
> > > Smurf Sound Font Editor. Along with the name change comes an
> > > entire object oriented source code re-write based on GObject
> > > with supporting libraries. Some of the most notable new features
> > > include:"iiwusynth" software SoundFont synthesizer support,
> > > removing the requirement of specialized hardware for SoundFont
> > > synthesis and delivering real time effects and SoundFont 2.01
> > > modulators for controlling generators via MIDI controls and more
> > > multi-item operations.
> > > 
> > > Swami website: http://swami.sourceforge.net
> > > 
> > > Developers wanted :)
> > >
> > 
> > hey Josh! congratulations on this release! I've been waiting for
> > it for a while now ;)  The only thing i still dislike is iiwusynth
> > being so incredibly slow :( Well, I'm downloading it!
> > 
> 
> Yes. This is something that is starting to be discussed again on the
> iiwusynth list, and is also my only gripe about it. Its gotten
> better though, a lot of it has to do with figuring out when voices
> have become perceptibly silent so they can be turned off or
> re-assigned. I'm not really doing much work on iiwusynth directly,
> since I've been pretty busy with Swami but I do manage to keep up on
> their discussions though. I think the synth sounds so good though
> that it somewhat out weighs the CPU consumption :) I'm certain it
> will get speedier though (like I said, it already has).
> 

Well, after my previous mail i've got the latest iiwusynth tarball,
compiled it, tried it and found out that it was as slow as allways..
so i went into the code and found the critical zone (dsp mixer)
I tried to fix it, but handt have much success since i dont know the
input/output ranges of the vars. I dont know if peter hanappe reads
lad, but here's the list of things that i think that need to be done
in order to gain way more speed.

1-Change iiwu_voice_run_dsp macro to an inlined function, because it's
just too anoying to code ;) And I dont think there's performance loss
since the critical zone is INSIDE the loop.

2 - Get rid of the iiwu_phase_t and replace it for a either a 64 bit
integer (long long) which represents a 32.32 fixed point value. This
way you can take advantage of using the ADC instruction in the cpu
Peter said in there that he took the code from mozilla, which i think
it's perfect from mozilla since probably by the time that such code
was written, many compilers didnt support 64 bit int vars. gcc is
smart enough. Also, the index/frac vars seemed to me to be pointed to
a global sample pool buffer. Something sucky about this is that you
cant use 32 bit fixed point vars, which are WAY more than enough for
this. And this is what i think should be the definivite choice (by
converting it to relative values to the begining of the mixing block
per each mixing, not even to the sample or pool)

3 - Convert the code for the volume ramp (amp/amp_incr) to fixed point

4 - Convert the filter code to fixed point, that code is just eating
badly the cpu

5 - Convert the buffers to integers and only convert them to float
when mixing them too freverb. 

6- basically, the less floats, the faster the mixer..  floats  are
slow, and will _never_ be faster (not even with SSE) than integers for
addition,  substraction and multiplication. If special cpu-specific
instruction sets are to be used (which i dont think it's worth it),
MMX alone is more than enough for this..

6-About the design of the filter/reverb/interpolation model...

I understand that peter is seeking an accurate player, but accuracy 
depend on certain things...

First, about using hermite curves for interpolation...
I personally think that this is pointless, because in multisampled
instruments, linear interpolation works the same and uses way less
CPU. Cubics in interpolation are known to smooth the sound a bit when
downsampling, which is good, except for the point that downsampling is
a bad idea when you work with multisamples. Also, when you create
multisamples you usually filter high freqs out of them so the mix
better at the end..  Thats why i think, cubic isnt that better than
linear...so it should be given as an option (besides linear) if you
want a bit more overall quality in exchange of CPU. Also, it's good if
you want to write your song using linear (To take advantage of the
cpu) and then switch to cubic for the final mix.

Second, about chourus and reverb... I notice that they are mono
buffers... but still your reverb implementation (i didnt check it well
but looks like freevrb) supports reverb width.. this is a bit odd to
have if the reverb buffer is mono. Also with a chorus buffer you cant
do stereo chorus either (where you can specify an opposite direction
for chorus to be mixed at, i did this in cheesetracker and sounds
really nice)


Also, i noticed that pitch events dont work in iiwusynth?

well, that's all for now!

cheers

Juan Linietsky






















reply via email to

[Prev in Thread] Current Thread [Next in Thread]