Re: [fluid-dev] What is the best way start fluidsynth with zero/low latency?

[Kevin Fishburne]

How difficult would it be to have FluidSynth generate (or come packaged with) a test sf2 file which would be played by FluidSynth and listened to programmatically for any problems? The script could run during package configuration or with a command line parameter like --calibrate. A pseudo-code example (without knowing much about FluidSynth unfortunately) could be:

# Test all possible settings and add the ones that work to ~/.fluidsynth/goodsettings.cfg
for output_device = 1 to 3
    for setting3 = best_quality3 to worst_quality3 step -1
        for setting2 = best_quality2 to worst_quality2 step -1
           for setting1 = best_quality1 to worst_quality1 step -1
               if test_sf2(output_device, setting1, setting2, setting3) = TRUE then add_settings_to_list(output_device, setting1, setting2, setting3)
           next setting1
        next setting2
    next setting3
next output_device

The test_sf2 function would play the test sf2 using the settings supplied by the for/next loops and listen for high latency and distortion. Distortion could hopefully be detected by the script if the test sf2 was something simple like a square or sine wave by looking for variations in amplitude (skipping or popping). Latency could be detected by calculating the time between sending the MIDI note data and getting an audio response from the device. If an error was returned then the settings would be discarded obviously.

Once the list of acceptable settings has been generated, the one to use as the default settings would automatically be chosen based on what are considered sane settings. In other words, if setting1 was the highest/best and setting2 was the lowest/worst then that would not be the preferred configuration. Rather the settings that were closer to being balanced would be chosen. An example would be:

Settings 1: high sample rate (good), high latency (bad)
Settings 2: low sample rate (bad), low latency (good)
Settings 3: medium sample rate (okay), medium latency (okay)

The script would choose Settings 3 as the default settings. The user could then list/modify the default settings from the command line or by editing the FluidSynth config file in their home directory.

A few things that would need to be considered would be:

Testing the various available output options (JACK, ALSA, OSS, etc.).
Checking for the presence of jackd and starting it when testing JACK.
Finding a way to programatically listen to and analyze audio sent to the various output devices.
Saving separate lists of good settings for each output option.
Choosing (or allowing the user to choose) the default output device.
Allowing the user to easily change the default output device.
Allowing the user to easily change the default saved settings.
Allowing the user to override the saved settings and specify all parameters manually.
Creating user-oriented documentation of these features.

I know that's probably going to be a terrible amount of work, so maybe it's better just to leave it alone.

Kevin Fishburne

Eight Virtues

www: e-mail: phone:

http://sales.eightvirtues.com  address@hidden  (770) 853-6271

Louis B. wrote:

The below email was sent just to me but I would like to share it with the list.

That is a really good idea, but a better idea might be to have a
"startfluid" script that is provided either by the distribution or is
part of the fluid synth team that works like the startx script. ie it
starts up fliud in the best manor with a GM sound set. I think it
would be best to have _one_ script that could be run by all the
different midi apps that want fluid started. PB could then call
start_fluid which would just start fluid with the best possible config
for that distribution. in an ideal world there would be no
distribution differences.

Just an idea any way. what do think about a startfluid script?

Louis

On Thu, May 21, 2009 at 11:38 PM, Joan Quintana <> wrote:
  

If QSynth crashes, I think that the problem is that, in setup, jack audio driver is selected. When you start QSynth it starts without -l option: doesn't try to start jack. So, if jack is not running, it crashes. Solution: first start jack; or use alsa audio driver directly.

In your case, a possible solution is: PB is launched by a script. This script first attempts to start fluidsynth, and later start PB. This script could be these two lines long, or 10ths lines: for instance, detect soundcards available... this script can also read a configuration file... PB could be great, but bash scripting and programming coud make it better.
    

_______________________________________________
fluid-dev mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/fluid-dev