Re: [fluid-dev] problems with fluidsynth 1.1.6 on a raspberry pi

[Aere Greenway]

David:

Establishing a score on a note to compare with other notes' scores, to determine which note to remove is an interesting idea.  

But there might be an easier way to determine whether a note can be killed or not.  I am merely speculating here, and don't know what information is visible to the code that decides to remove a note.  

Many instruments have a sound that fades-away with time, regardless whether or not the sustain-pedal is pressed.  The volume it fades-to is probably what is maintained sounding by the sustain-pedal.  

Although percussion instruments (in a rhythm-track) are important for keeping the other instruments together, many percussion instruments (such as a wood-block) are the type whose sound quickly fades to a barely audible (or inaudible) level.  Also, the sustain pedal doesn't seem to affect them.  

Likewise, a guitar sound has a strong attack sound, but quickly fades to a lower level.  

Playing a guitar voice with the sustain-pedal held down changes the sound, making it generally richer and more full, but it doesn't have as noticeable an effect as playing a piano voice with the sustain-pedal held down.  

On the other hand, very many instruments (such as on oboe, trumpet, or French horn, to name a few), have a high volume-level for the sustained note (which is lower than the attack-phase of the note).  In performing/recording a track for such instruments, I generally don't use the sustain pedal, but will use it if I need to keep a note playing while I re-position my hand to play the next phrase.  

If the software is aware of the volume level of notes still sounding, it would seem logical (to me) that if a note is no longer sounding at an audible (or barely audible) level, the note could be removed without making a noticeable change to the sound.  

So it makes sense that the volume level of a note is a very important (perhaps most-important) part of the score used to determine if a note could be removed.  Certainly if a note is no longer audible (even though the sustain pedal is depressed) it could be removed with impunity.  

I would therefore like to experiment with these parameters.  

In Qsynth, using the "Setup" button, if I click on the "Settings" tab and scroll down (the parameters are in alphabetical order), I can see the various "synth.overflow.*" parameters.  However, I know of no way to change the parameters displayed in the "Settings" tab.  This tab appears to only be used to display the current settings of all of the parameters, some of which can be set elsewhere.  

For example, you can change the Polyphony parameter on the "Audio" tab, and its new value will be displayed in the "Settings" tab.  

I normally use Qsynth, and am thinking there is no way (at least in the GUI) to change the parameters.  

In looking at the man-page for Qsynth, I saw the following option info:

       -o, --option [name=value]
              Define a setting name=value

Using that information, I fired-up qsynth using the following line (entered from a terminal):

qsynth -o synth.overflow.volume=4321

The GUI came up, and on hitting the "Setup" button, and selecting the "Settings" tab, I found the specified value (4321) was set for the synth.overflow.volume parameter.  

Specifying the value that way appears to only affect the 1st qsynth 'engine', but still, it gives me a way to experiment with the parameters.  

Thank you for the information.  I will experiment with the parameters. 

Perhaps this will work to solve qsynth's problems with my pieces, without having to install your PPA fix to libfluidsynth1 in Ubuntu 12.04.  

If you can tell me which values were already present in the code in hard-coded form (without too much research to find the information), it would be helpful to me.  

-- 
Sincerely,
Aere

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