[fluid-dev] Testing synth.overflow parameters - more questions

[Aere Greenway]

David:

I am starting to test the "synth.overflow" parameters, but find I still 
have a point of confusion.

I have always been thinking on a per-note basis, in which case, the 
situation is easier to understand.

But where the algorithm is "per voice", I am having problems 
understanding how it works.

My typical case where I want old notes to 'drop-out', is for a voice 
(track?) where I am playing the piano.  I tend to use the sustain-pedal 
a lot, and hope (and have assumed) that older, sustained notes, would be 
discarded.

On the other hand, my solo-instrument voices (oboe, cello, choir Aahs, 
etc) I would never want to cut out (and I never use the sustain pedal on 
them for more than a very short time).

I have put the piano track as a higher-number track, because it seems 
(on the synthesizers I use) the higher-number track notes are more 
likely to have their notes discarded.

So anyway, to clear up my confusion, I need to know more precisely what 
you mean by 'per voice'.

My assumption (which seems to make little sense), is that a 'voice' is 
all sound being made by a particular instrument sound (patch), which 
could even be in different tracks (such as if you have one track for the 
right-hand, and one track for the left-hand).

Given that (hopefully incorrect) assumption, it is horrifying to me that 
based on a score, the algorithm would take-out an entire voice (all 
notes on a track (or tracks) using the same voice) for a new note that 
needs to be played.  Yet when fluidsynth gets in its 'bad state', it 
seemed to do just that (before the problem was fixed).

I am thinking my assumption is incorrect, because I don't see how the 
synth.overflow parameters could work on a voice as a whole.  For 
example, you reference note-off events having been sent, which are for 
individual notes.  The 'age' concept would have to be (I hope) on a 
per-note basis.

If you could please explain more precisely what you mean by 'per voice', 
it would help me a lot.

--

Sincerely,
Aere


-------- Forwarded Message --------
*From*: David Henningsson <address@hidden 
<mailto:address@hidden>>
*To*: Aere Greenway <address@hidden 
<mailto:address@hidden>>
*Subject*: Re: [fluid-dev] problems with fluidsynth 1.1.6 on a raspberry pi
*Date*: Sun, 16 Dec 2012 10:56:13 +0100

On 12/16/2012 06:31 AM, Aere Greenway wrote:
> David, and all:
>
> Regarding the following paragraph in an e-mail from David:
>
> This is controlled by the synth.overflow.* parameters which I
> implemented a while ago to give you others some room for experimenting
> with which settings work best. I don't remember if I got any feedback
> for changing the default parameters.
>
> It may well be that the implementation of the "overflow" parameter
> functionality was the beginning of when fluidsynth lost its ability to
> successfully play my compositions.
>
> I would like to experiment with the parameter, but in looking at the
> help info from fluidsynth, it is not self-evident (to me) how to use it,
> or what it does.

I would be glad for some input on good default values on these
parameters; I more or less set them arbitrarily and was hoping for some
feedback. Some of the values were hard-coded before I turned them into
parameters.

It does not look like I documented it very well, so here comes some
ad-hoc documentation.

In a voice overflow situation, i e, when you must kill a previous voice
to leave room for the new one to start playing, all voices are given a
score, and the one with the lowest score is killed.

> Here is the information I got from the help:

> synth.overflow.percussion FLOAT [min=-10000.000, max=10000.000,
> def=4000.000]

Some people think drum channels are more important than other channels.
If we're on a drum channel, add this score.

> synth.overflow.released  FLOAT [min=-10000.000, max=10000.000,
> def=-2000.000]

Added if the note has been released, i e, a noteoff command has been
sent (and no sustain pedal keeping it alive). Normally below zero, i e,
less important.

> synth.overflow.sustained FLOAT [min=-10000.000, max=10000.000,
> def=-1000.000]

Added if the note has been sustained, i e, a noteoff command has been
sent, but the sustain pedal is held down. Normally below zero, i e, less
important.

Those are the simple ones; the below are slightly more complex:

> synth.overflow.volume    FLOAT [min=-10000.000, max=10000.000, def=500.000]

If a voice has higher volume, then higher score. This only applies to
voices not in their release phase.

The score added is volume_score / attenuation, where attenuation in turn
is based on the attenuation modulator.

(Looking at this now; maybe it would have been better to use the
amplification used when mixing into the main buffers? Or maybe both,
multiplied?)

 > synth.overflow.age       FLOAT [min=-10000.000, max=10000.000,
def=1000.000]

Here newer notes get an extra score. The score added is age_score / time
(in seconds), so given a score of 1000, a voice 1 s old gives a score of
1000, 2 s gives 500, 1/2 s gives a score of 2000. And so on.

> I searched for more documentation, but didn't find it.
>
> Could you please explain the various overflow parameter settings, and
> what they do?
>
> Also, is it possible to specify the overflow parameters in Qsynth?

I don't know.

> --
>
> Thank You,
> Aere
>
>
> -----Original Message-----
> *From*: David Henningsson <address@hidden  <mailto:address@hidden>
> <mailto:address@hidden>>
> *To*: FluidSynth mailing list <address@hidden  <mailto:address@hidden>
> <mailto:address@hidden>>
> *Subject*: Re: [fluid-dev] problems with fluidsynth 1.1.6 on a raspberry pi
> *Date*: Tue, 20 Nov 2012 22:57:39 +0100
>
> On 11/20/2012 08:58 AM, Jan Newmarch wrote:
> > Hi
> >
> > I recompiled 1.1.6 with polyphony set to 64. There doesn't seem to be a
> > command line option to reset parameters like this, but it shouldn't be
> > too hard to add one. Yes I know, use fluid_settings_setXXX in the code...
>
> The option is:
> "fluidsynth -o synth.polyphony=64"
> see "fluidsynth -o help" for more settings.
>
> Unfortunately it does not seem like the interpolation method is settable
> in the same way, which seems strange to me. You have to do it inside the
> shell.
>
> Turning off reverb and chorus, as suggested by others, is done by "-o
> synth.reverb.active=False" and "-o synth.chorus.active=False", which
> might also speed up fluid_rvoice_buffers_mix (no need to render into
> reverb and chorus buffers).
>
> > Anyway... no better. Still hits CPU above 99% (!) and distorts
> > accordingly.
> >
> > (The pidstat command I used was
> >         pidtat -C fluidsynth - u -r 5
> > for 5 second periods.)
> >
> > David gives perf figures of
> >
> >          30% - fluid_rvoice_dsp_interpolate_4th_order
> >          27% - fluid_rvoice_buffers_mix
> >          13% - fluid_iir_filter_apply
> >            9% - fluid_revmodel_processmix
> >
> > I ran perf (from linux-tools Debian pkg) on the RPi for nightsin.kar using two 
> > soundfonts and got
> >
> >      32.07%   fluid_rvoice_buffers_mix
> >      26.89%   fluid_rvoice_dsp_interpolate_4th_order
> >      12.99%   fluid_iir_filter_apply
> >      11.00%   fluid_revmodel_processmi
> >
> > for the FluidR3_Gm  and
> >
> >      29.49%   fluid_rvoice_buffers_mix
> >      23.71%   fluid_rvoice_dsp_interpolate_4th_order
> >      14.89%   fluid_revmodel_processmix
> >      12.53%   fluid_iir_filter_apply
> >
> > for the GeneralUser soundfont (which sounds a bit better).
> > No significant difference.
>
> Thanks, seems like the statistics are about the same; with
> fluid_rvoice_buffers_mix being on the top.
>
> Are you running this with floats or doubles, (-Denable-floats=on when
> compiling for single-precision floats) and is there a significance in
> performance?
>
> > Jan
> > --
> >
> > On Sun, 2012-11-18 at 08:31 -0700, Aere Greenway wrote:
> > > Jan & David:
> > >
> > > In my opinion, limiting the polyphony (I presume that is what you mean
> > > by "limiting the voices") does not adversely affect the sound.
> > >
> > > What is using up the CPU, is voices still being 'sounded' that have
> > > long before faded to where they are inaudible.  sysstat
> >
> > > If Fluidsynth works similarly to the EMU10K1/2 (Soundblaster & Audigy)
> > > chip, it should 'take-out' the oldest voices first, though I don't
> > > know if that is actually the case.
>
> This is controlled by the synth.overflow.* parameters which I
> implemented a while ago to give you others some room for experimenting
> with which settings work best. I don't remember if I got any feedback
> for changing the default parameters.
>
> // David