Selecting the sample rate

[jimhen3ry]

Selecting a sample rate can be important but difficult for end users. The wrong choice can add additional resampling or even pitch errors. The fluidsynth.exe -Q command provides a report of a probe of all available soundcards for supported modes, sample-rates and sample-formats. That information could be used to help users make a better choice for a sample rate. I am unable to find a way to do this type of probe programmatically through the API. Am I missing something?

[syntaro]

Sorry it's not an answer. but I am thinking this is depend on Audio Driver.

my c lib have 3 lines.
fluid_settings_setstr(handle->settings, "audio.driver", "oboe");
fluid_settings_setnum(handle->settings, "synth.sample-rate", sampleRate);
fluid_settings_setstr(handle->settings, "audio.oboe.sample-rate-conversion-quality","Best");

and Java call it like these lines.
int sampleRate = 0;
try {
AudioManager am = (AudioManager)context.getSystemService(Context.AUDIO_SERVICE);
String sampleRateStr = am.getProperty(AudioManager.PROPERTY_OUTPUT_SAMPLE_RATE);
sampleRate = Integer.parseInt(sampleRateStr);
}catch (Throwable ex) {
}
Android need java architecture for detect this. Google said do it.
And, Which sound driver are you using?

[jimhen3ry]

I am modernizing an app, the Miditzer, that has included FluidSynth since before 1.0. At this time it only runs on Windows. We are dropping support for dsound and adding wasapi. During testing we found that it is easy to make a bad choice for the FluidSynth sample rate that leads to pitch being off by several semitones. We are trying to figure out how to help users make a good choice. It seems like making the default sample rate 48 kHz will at least have a greater number of users with a good choice. We are hoping that we can find a way to use FluidSynth to help with finding a good sample rate since it is closer to the driver/hardware interface where the matching needs to occur.

[syntaro]

I see. If fluidsynth audio driver having feature (announce better sampling rate) offcause I wish it.

[derselbst]

fluidsynth -Q executes this file, whose functionality is currently not exposed via the public API. You'll see that it simply sets a few settings, creates an audio driver and monitors the log messages printed by that driver. Because WASAPI is currently the only driver for which this matters, I would refrain from adding this to our public API and instead encourage you to replicate this logic in your code.

[jimhen3ry]

Thank you! That short file offered several hints about using the WASAPI driver in Windows, both to query the OS capabilities and to use the driver more generally. Perhaps the audio.wasapi.device setting documentation could be extended to include this useful information? Here is possible verbage:

audio.wasapi.device

Type
   String (str)
Default
   default
Device to use for WASAPI driver output. Starting with 2.3.6 all device names are expected to be UTF8 encoded.

Note
When using the WASAPI audio driver, more detailed information about device and format negotiation (e.g. whether the requested format was accepted natively, adjusted, or rejected) may be obtained by installing a custom log callback using fluid_set_log_function().

The WASAPI driver reports informational, warning, and error messages received from the OS during device initialization, which can be used as a best-effort heuristic to distinguish between:
   successful native opens
   successful opens with format adjustment or resampling
   failed opens
This mechanism is used internally by the fluidsynth -Q command; see https://github.com/FluidSynth/fluidsynth/blob/master/src/fluid_wasapi_device_enumerate.c for a reference implementation. The content and meaning of log messages are not part of the public API contract and may change between releases.

[derselbst]

Done