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: Juan Linietsky
Subject: Re: [iiwusynth-devel] Fw: Re: [linux-audio-dev] more about iiwusynth
Date: Fri, 7 Jun 2002 11:11:19 -0300

On Fri, 07 Jun 2002 13:00:24 +0300
"M. Nentwig" <address@hidden> wrote:

> > 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 conversion short to float is done at the same time: (from
> iiwu_voice.c):
>  /* correct the amplitude for the short to float conversion. */
>   amp /= 32768.0f;
>   amp_incr = (amp - voice->amp) / IIWU_BUFSIZE;
>   amp = voice->amp;

Ok thanks!, now I need to know the ranges of amp (what values for max
and min volume?)

> With the limited number of bits, it may well be, that this is the
> cause of some quantization noise I keep hearing (when notes are
> fading out)...

Personally I use 32 bits integer buffers. It's just better than float
buffers (9 bits more of precision, and values dont wrap on add/sub)
and faster. Also it works great because the only thing you do is to
take 16 bit ints, multiply for volume, process filter and save back.
Anyway, so do you mean that the max value PER sample is -1 .. 1?

> 
> >
> > > 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.
> >
> 
> In my opinion 1 ms (441 samples) would still be acceptable for
> real-time playing. Midi interfaces are that fast and use interrupts.

Yes, midi interfaces use interrupts, but I was talking about what i
think most people uses iiwusynth for, which is as sampler from
programs such as  muse, jazz, or shake. For those, the minimum latency
unit is 10ms. Even with that you cant really hear any delay (hey even
a piano hammer takes around that to hit the string, or the air to pass
through a horn). I see you are a vintage dreams fan too, i love that
little soundfont.. we should exchange some music ;) Maybe precision
(size of the mix block) is another value you'd like to specify from
command line..

> There will be different optimum tradeoffs between speed and quality,
> depending on what you want to use the synth for. I use it for
> real-time playing, never more than 10 fingers, so I see myself
> tending more towards the 'quality' corner. But let's find a good
> compromise in the middle and optimize that, we'll probably get a
> better result than implementing different options.

Ahh, now I see.. I use the synth for full pieces (something that takes
around 60+ voices), thats why i find iiwusynth to be too limiting.
Also when you mix that many voices, interpolation quality doesnt play
an important role either..

Regards!

Juan Linietsky



reply via email to

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