|Subject:||Re: [fluid-dev] What is the best way start fluidsynth with zero/low latency?|
|Date:||Thu, 21 May 2009 20:38:49 -0400|
|User-agent:||Thunderbird 22.214.171.124 (X11/20090409)|
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)
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.
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
|[Prev in Thread]||Current Thread||[Next in Thread]|