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

[Juan Linietsky]

On Fri, 07 Jun 2002 10:42:11 +0300
"M. Nentwig" <address@hidden> wrote:

> 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.
> 

Ok, I've already started writing a fixed point implementation, but i
have certain problems, I hope i can be helped on this...
which basically are

First the amp/amp_incr vars (for volume smoothing and volume ramping).
>From what I see, the values on these vars are amazingly low, what kind
of final value ranges is the mixing buffer expecting? I suppose quite
low since floats can only store 23 bits stuff...


> 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:

Isnt 64 chunks incredibly low?
like, if i play at 44100hz.. 44100/64 .. somewhat around 700
iterations per second is insane. If we take in consideration that the
internal midi timer resolution is around 10ms (limited to the x86
clock).. which means around 100 iterations. As for "response" times
(lapse between which you change variables), not even trackers go that
low. This is kind of pointless specially if you use volume ramps.

 
> - 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.

That's my approach, which i almost finished.. my only problem is that
i dont know the ranges expected by the destination buffers...

> 
> 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 :-)
> 

For now i dont think it's much fo an issue, I have a filter
implementation in cheesetracker which only uses 1 gain and 2
coheficients, but i doubt it's worth changing it for now.

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

oh, ok.. I thought it actually did reverb width based on pan.

> 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.

Hehe, well, as I said before, (wow 9 is insane), Linear is not really
that bad. Linear interpolatin aliases high frequencies, which is
something that doesnt matter much if you are using multisampled
instruments. For now i'm going to do that implementation, and later
will probably add a hermite curve interpolation for high quality..
and maybe even a fir interpolation would be nice. (I still think that
linear is just only around 85% the quality of cubic or more, so that's
why i'm not worried)


Regards!

Juan Linietsky