iiwusynth-devel
[Top][All Lists]
Advanced

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

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


From: M. Nentwig
Subject: RE: [iiwusynth-devel] Fw: Re: [linux-audio-dev] more about iiwusynth
Date: Fri, 07 Jun 2002 10:42:11 +0300

Hello,

I think a faster synth is a better synth, as long as people (like me)
can still understand the code.

A fixed point implementation for the DSP loop would surely speed up
things. If you are willing to make some experiments, that's great and
I'll try to help. Probably the best approach is that I put comments into
the code, where something is unclear or missing.

The DSP loop works in chunks of 64 samples (more if you increase the
buffer size), so anything outside of run_dsp will not affect the
performance much, even if it's still float. So I'd approach it like
this, for a start:

- Retrieve amplitude, phase, ... and convert to fixed point
- run_dsp in fixed point
- Convert back to float and store

That isn't optimal, but doesn't require a complete rewrite of the synth
core.

One place to save is the filter; there are resonant two-pole LPs out
there, which use less coefficients than my off-the-shelf, standard-issue
low-cost heavy-duty filter implementation :-)

By the way: The freeverb is mono-in but stereo-out.

And thinking about interpolation: EMU uses eight (9?) point
interpolation and the specs are tailored to that. Linear interpolation
could probably be a low-quality option, but the aliasing is just too
bad.

Cheers

Markus


> -----Original Message-----
> From: ext Juan Linietsky [mailto:address@hidden
> Sent: 07 June 2002 00:59
> To: address@hidden
> Subject: [iiwusynth-devel] Fw: Re: [linux-audio-dev] more about
> iiwusynth
>
>
> 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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> iiwusynth-devel mailing list
> address@hidden
> http://mail.freesoftware.fsf.org/mailman/listinfo/iiwusynth-devel
>




reply via email to

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