Default synth.gain for 2.4.0 and higher of 0.6 is too high

ReinholdH commented 1 day ago

FluidSynth version

master (as of Sun. Oct. 13th, 2024) to become 2.4.0

Describe the bug

Default "synth.gain" for 2.4.0 and higher of 0.6 is too high

Expected behavior

Some midi files run into clipping now with "audio.driver", "file"

Steps to reproduce

Use Dance.mid from https://schristiancollins.com/generaluser.php which is part of the GeneralUser GS 2.0.0. Clipping happens at ~40 sec.

Additional context

For 2.4.0 and higher the default synth gain is planned to change from 0.2 to 0.6 (see https://www.fluidsynth.org/api/settings_synth.html#settings_synth_gain). I have been doing intensive testing with the upcoming 2.4.0 and ran into this issue. Of course, the gain can be initialized with fluid_synth_set_gain. But going from 2.6.3 to 2.4.0 requires a code change now. It took me quite some time to find out why Dance.mid is now clipping in audio export files but is not in 2.6.3. Of course, using fluid_synth_set_gain to initialize the gain is always a good idea.

ReinholdH commented 1 day ago

I meant 2.3.6 composer to 2.4.0

ReinholdH commented 1 day ago

ogg format does not clip with 0.6 but for wav, flac, mp3 clipping happens

derselbst commented 1 day ago

Thanks Reinhold for investigating! It seems that using 0.3 wouldn't clip.

@es20490446e You have introduced the new gain in #1287, any preference of using 0.2 or 0.3? A more solid solution for this may lie in #1302.

ogg format does not clip with 0.6

OGG is a special case as it uses floats inside libsndfile, which are scaled as postprocessing step to prevent most clippings.

ReinholdH commented 1 day ago

Thanks for the immediate response.

Yes, 0.3 is fine (0.35 may still work but 0.4 clips). 0.3 is on the safe side.

es20490446e commented 1 day ago

I chose 0.6 because it provided a good balanced between foreground dialogs and effects, and background music, when using Fluidsynth on old games.

The previous setting of 0.2 made the background music mostly inaudible, and weirdly low when played through the media played compared with non midi music.

So I made the volume just a bit lower than non midi files. That didn't result in any clipping I could perceive. Either in the VLC media player, DosBox or Wine.

This is by using GeneralUserGs, which samples are a bit quieter than those from the Fluid sound-font.

I took GeneralUserGs as reference because I think it's more balanced, realistic and intended for a broader user case.

I have tried reproducing the clipping, but I have been unable to. See the used code here: Fluidsynth.zip

I have tried:

audio-driver: alsa vs file
midi-driver: alsa vs alsa_raw vs oss
audio-bufsize: default vs 1024
sample-rate: 44000 vs 48000
audio-file-type: oga vs flac (32-bit) vs wav (16-bit)
Playing output files: vlc vs terminal vs android-vlc vs android-mi-player
Recording files vs Playing them through the terminal

My system is:

Arch Linux
Linux Zen 6.11.3
Fluidsynth 2.3.6 + Fluidsynth-git settings
GeneralUserGS 2.0
Pipewire 1.2.5
Realtek ALC257
i7-10750H 12-cores 2.6GHz

I suspect that my audio processor (Pipewire) or my sound chip (Realtek) prevent the clipping all together. We would need to bisect this.

Please:

Try if you can hear clipping in my audio samples.
Share the audio samples created in your system.
Tell me in what kind of system and configuration you are experiencing the clipping.

Also I think that lowering the gain to a very quiet level is really solving nothing.

It's just a work-around, and many consumer software will raise the gain to a louder level anyway.

ReinholdH commented 1 day ago

As said, clipping with gain 0.6 only happens for "audio.driver", "file". Clipping only happens for the audio formats wav, and wav converted to mp3 (with lame), flac (with libFLAC etc). No clipping for ogg (libogg etc). Any other driver like Directsound, WASAPI + exclusive, portaudio + ASIO, Jack is OK. For these other ones I use 0.7 w/o clipping.

Arch: Windows 10 latest update Processor: Intel(R) Core(TM) i9-10850K CPU @ 3.60GHz with 10 cores ("synth.cpu-cores" is used) Sountfont: GeneralUserGS 2.0 + recommended fluidsynth settings, but other soundfont like FluidR3_GM2-2 create clippng with 0.6 as well Sample rate: for both 44100 KHz + 48000 kHz

With regards to sharing the Dance.mid audio samples I have my concerns. Not sure that these are w/o property rights.

In order to be on the safe side I now use the gain setting for "synth.gain" to be initialized for my needs. The problem is now solved for me.

My point is that 0.2 has been the default value since ever, at least for the past 10 years. Increasing the default now to 0.6 - all of a sudden with 2.4.0 - causes clipping where I ran into. This could have been avoided.

es20490446e commented 1 day ago

I have tested it with:

audio-driver: file
midi-driver: file
sample-rate: 44000
audio-file-type: wav (16-bit)

But the clipping didn't occur. I will need to keep discarding factors.

By the way, what is your sound card?

ReinholdH commented 16 hours ago

I did not mention the sound card because for "audio.driver", "file" IMHO the sound card is irrelevant.

We hear clipping by a gain of 0.6 on all of the different PC types in our lab: from a 2008 old Intel Core 2 P8400 PC with Windows, on the PC mentioned above, on Linux Wine installations as well as on a Mac with macOS Sequoia running our x64 app on top of Wine on an Apple M-processor where the object code is converted by Rosetta 2 (which is still unbelievable fast).

We have our app in thousands of installations in the market since almost 10 years and never had any complain by a customer with the default gain 0.2. Of course, the gain can be modified. But 0.6 is definitely to high. @es20490446e : I respectfully disagree your point that "...lowering the gain to a very quiet level is really solving nothing." It resolves the clipping, definitely. In my view 0.2 is not "very quiet". It is more quiet than 0.6. For me, 0.3 is a very good value.

To me a "default value" should cover most of the cases. Changing a default value which is in place for so long due to a special configuration (old games, Linux, Pipewire etc.) is not the right step. In such as case the gain should be set by

fluid_settings_setnum(s_settings, "synth.gain", 0.6f); or by the command parameter option -g

as you did it in your examples (when I read them correctly) but not by changing the "default value" in the fluidsynth code.

As said above, the problem is resolved for us. We initialize the value in the future for our needs.

@derselbst: in case of a change from 0.2 to something new please do not forget to change print_help in fluidsynth.c "Set the master gain [0 < gain < 10, default = 0.2]"

es20490446e commented 9 hours ago

That's why I'm asking you if you could provide some recorded file where you hear clipping, and that I can try rendering on my machine too.

So if I notice a difference between the two resulting files, to figure out why I'm not hearing any clipping at all.

In general I'm against changing anything that will break retrocompatibility, but I suspect that in this instance we are rather exposing a defect that needs to be addressed in a different fashion.

es20490446e commented 2 hours ago

For the moment being I have been unable to reproduce it on Arch Linux with pipewire, or Ubuntu with PulseAudio.

I tried testing it on Windows, but it took several hours to set up and I finally gave up.

FluidSynth / fluidsynth