[Top][All Lists]

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

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

From: Aere Greenway
Subject: [fluid-dev] Testing synth.overflow parameters - more questions
Date: Sun, 27 Jan 2013 12:07:43 -0700
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2


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.



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

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,

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,

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,

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

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,

 > synth.overflow.age       FLOAT [min=-10000.000, max=10000.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,

-----Original Message-----
*From*: David Henningsson <address@hidden  <mailto:address@hidden>
*To*: FluidSynth mailing list <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:

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

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

(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


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

reply via email to

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