[PATCH] FluidSynth backend for SDL_mixer

SDL Development
1

Hello everyone,

Attached is a patch to add a FluidSynth backend to SDL_mixer. This
patch has been some time in the making but I now believe it is finally
ready.

If you want to try it, it requires the latest FluidSynth from
Subversion. The patch was created against the latest SDL_mixer from
Mercurial but you can apply it against 1.2.11 while safely ignoring the
Makefile.in conflict. Don’t forget to run ./autogen.sh. I have tested
that it works under 64-bit Linux and have tested that it builds under
32-bit MSVC 2010. I wasn’t able to actually run it under Windows due to
audio issues I’m having with QEMU at the moment but I’m confident that
it’ll work.

Unlike Timidity, FluidSynth isn’t usually distributed with any sounds
so you either have to set the SDL_SOUNDFONTS environment variable to
some path or the game can call Mix_SetSoundFonts. The latter takes
priority but if you want to override it, set SDL_FORCE_SOUNDFONTS to 1.

You probably won’t need to but you can specify more than one SoundFont
file at a time, concatenating them with ; on Windows or : on Linux. To
prevent confusion, ; will also work on Linux but it needs to be quoted
on the command line, which is why : is preferred.

Since FluidSynth requires some conditions to be met while Timidity
doesn’t, FluidSynth is attempted first. It will fall back to Timidity
if no SoundFonts are requested by either method or if the requested
SoundFont files are not accessible.

Because the backend is determined when Mix_OpenAudio is called,
Mix_SetSoundFonts needs to be called before this. You can call it again
to change the SoundFonts later but by this time, it’s too late to fall
back to Timidity so if the given SoundFonts don’t work for any reason,
you’ll just get silence! I have considered whether it would be better
to determine the backend on each song load instead but there doesn’t
seem to be a strong need for it.

Mix_SetSoundFonts (as well as Mix_GetSoundFonts and Mix_EachSoundFont)
are intended to be generic functions in case the other MIDI backends
ever add support for SoundFonts. You can therefore use them without
worrying whether the user has enabled FluidSynth support or not.

Like the other external dependencies, I have made it possible to load
FluidSynth dynamically. I was able to use a macro to greatly shorten
the code needed to do this. It works really well and could be applied
to the other dependencies so take a look.

I have included the necessary changes to the project files in the
VisualC directory but I decided not to pollute the patch with the
FluidSynth DLL and headers so these will need to be added in the same
manner as the other dependencies.

Even though the required FluidSynth code hasn’t yet been put into a
release, it should be safe to merge this patch now because configure
specifically checks for the new function (fluid_player_add_mem) that
makes this work.

I think that covers everything. Feedback and suggestions welcome. :slight_smile:

Cheers,
James
-------------- next part --------------
A non-text attachment was scrubbed…
Name: sdl-mixer-fluidsynth.patch
Type: text/x-patch
Size: 34818 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20110320/9cb9c207/attachment.bin

2

I’m looking at the possibility of bundling SDL_mixer with the commercial
license option for SDL 1.3.

Do you give me permission to release your contributions to SDL_mixer
under both the LGPL and a closed-source commercial license?

Thanks!On Sun, Mar 20, 2011 at 9:55 AM, James Le Cuirot wrote:

Hello everyone,

Attached is a patch to add a FluidSynth backend to SDL_mixer. This
patch has been some time in the making but I now believe it is finally
ready.

If you want to try it, it requires the latest FluidSynth from
Subversion. The patch was created against the latest SDL_mixer from
Mercurial but you can apply it against 1.2.11 while safely ignoring the
Makefile.in conflict. Don’t forget to run ./autogen.sh. I have tested
that it works under 64-bit Linux and have tested that it builds under
32-bit MSVC 2010. I wasn’t able to actually run it under Windows due to
audio issues I’m having with QEMU at the moment but I’m confident that
it’ll work.

Unlike Timidity, FluidSynth isn’t usually distributed with any sounds
so you either have to set the SDL_SOUNDFONTS environment variable to
some path or the game can call Mix_SetSoundFonts. The latter takes
priority but if you want to override it, set SDL_FORCE_SOUNDFONTS to 1.

You probably won’t need to but you can specify more than one SoundFont
file at a time, concatenating them with ; on Windows or : on Linux. To
prevent confusion, ; will also work on Linux but it needs to be quoted
on the command line, which is why : is preferred.

Since FluidSynth requires some conditions to be met while Timidity
doesn’t, FluidSynth is attempted first. It will fall back to Timidity
if no SoundFonts are requested by either method or if the requested
SoundFont files are not accessible.

Because the backend is determined when Mix_OpenAudio is called,
Mix_SetSoundFonts needs to be called before this. You can call it again
to change the SoundFonts later but by this time, it’s too late to fall
back to Timidity so if the given SoundFonts don’t work for any reason,
you’ll just get silence! I have considered whether it would be better
to determine the backend on each song load instead but there doesn’t
seem to be a strong need for it.

Mix_SetSoundFonts (as well as Mix_GetSoundFonts and Mix_EachSoundFont)
are intended to be generic functions in case the other MIDI backends
ever add support for SoundFonts. You can therefore use them without
worrying whether the user has enabled FluidSynth support or not.

Like the other external dependencies, I have made it possible to load
FluidSynth dynamically. I was able to use a macro to greatly shorten
the code needed to do this. It works really well and could be applied
to the other dependencies so take a look.

I have included the necessary changes to the project files in the
VisualC directory but I decided not to pollute the patch with the
FluidSynth DLL and headers so these will need to be added in the same
manner as the other dependencies.

Even though the required FluidSynth code hasn’t yet been put into a
release, it should be safe to merge this patch now because configure
specifically checks for the new function (fluid_player_add_mem) that
makes this work.

I think that covers everything. Feedback and suggestions welcome. :slight_smile:

Cheers,
James

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
-Sam Lantinga, Founder and CEO, Galaxy Gameworks

3

I’m looking at the possibility of bundling SDL_mixer with the
commercial license option for SDL 1.3.

Do you give me permission to release your contributions to SDL_mixer
under both the LGPL and a closed-source commercial license?

Thanks!

I’m not a huge fan of such licenses since the LGPL seems like a fair
compromise to me but I’m guessing that not giving you permission would
make things awkward. Then again, some of the native MIDI code is
GPL-only so this wouldn’t be the only exception. Even though this is
probably my most significant open source contribution to date, I
suppose it’s not that big in the grand scheme of things. Thinking of
the bigger picture, I would like to see SDL more widely adopted.
Chances are that a big commercial project wouldn’t even use MIDI
anyway. Soooo… yeah, alright. Sorry for the brain dump. :wink:

JamesOn Mon, 21 Mar 2011 16:56:18 -0700 Sam Lantinga wrote:

4

Okay, thanks!On Mon, Mar 21, 2011 at 5:41 PM, James Le Cuirot wrote:

On Mon, 21 Mar 2011 16:56:18 -0700 Sam Lantinga <@slouken> wrote:

I’m looking at the possibility of bundling SDL_mixer with the
commercial license option for SDL 1.3.

Do you give me permission to release your contributions to SDL_mixer
under both the LGPL and a closed-source commercial license?

Thanks!

I’m not a huge fan of such licenses since the LGPL seems like a fair
compromise to me but I’m guessing that not giving you permission would
make things awkward. Then again, some of the native MIDI code is
GPL-only so this wouldn’t be the only exception. Even though this is
probably my most significant open source contribution to date, I
suppose it’s not that big in the grand scheme of things. Thinking of
the bigger picture, I would like to see SDL more widely adopted.
Chances are that a big commercial project wouldn’t even use MIDI
anyway. Soooo… yeah, alright. Sorry for the brain dump. :wink:

James

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
-Sam Lantinga, Founder and CEO, Galaxy Gameworks

5

I’m looking at the possibility of bundling SDL_mixer with the
commercial license option for SDL 1.3.

Do you give me permission to release your contributions to SDL_mixer
under both the LGPL and a closed-source commercial license?

Thanks!

I’m not a huge fan of such licenses since the LGPL seems like a fair
compromise to me but I’m guessing that not giving you permission would
make things awkward. Then again, some of the native MIDI code is
GPL-only so this wouldn’t be the only exception. Even though this is
probably my most significant open source contribution to date, I
suppose it’s not that big in the grand scheme of things. Thinking of
the bigger picture, I would like to see SDL more widely adopted.
Chances are that a big commercial project wouldn’t even use MIDI
anyway. Soooo… yeah, alright. Sorry for the brain dump. :wink:

It’s for the iPhone devs. Apple doesn’t let you use dynamically-linked
libraries for iOS, and statically linking a LGPL library can be done but
it’s more trouble than it’s worth, so another solution is required.>----- Original Message ----

From: James Le Cuirot
Subject: Re: [SDL] [PATCH] FluidSynth backend for SDL_mixer
On Mon, 21 Mar 2011 16:56:18 -0700 Sam Lantinga wrote:

6

trouble as in releasing the source code you are linking to? i see only
benefits from that :slight_smile:
VittorioOn Tue, Mar 22, 2011 at 3:08 AM, Mason Wheeler wrote:

It’s for the iPhone devs. ?Apple doesn’t let you use dynamically-linked
libraries for iOS, and statically linking a LGPL library can be done but
it’s more trouble than it’s worth, so another solution is required.

7

It’s for the iPhone devs. Apple doesn’t let you use
dynamically-linked libraries for iOS, and statically linking a LGPL
library can be done but it’s more trouble than it’s worth, so another
solution is required.

Fair enough. At least I know who to blame now. ;)On Mon, 21 Mar 2011 19:08:48 -0700 (PDT) Mason Wheeler wrote:

8

It’s for the iPhone devs. ?Apple doesn’t let you use dynamically-linked
libraries for iOS, and statically linking a LGPL library can be done but
it’s more trouble than it’s worth, so another solution is required.

trouble as in releasing the source code you are linking to? i see only
benefits from that :slight_smile:

Ordinarily, you don’t even need to do that with LGPL–a linkable object
file is enough. Unfortunately, none of the LGPL solutions work in this
case, since the app store imposes restrictions on redistribution which are
incompatible with the LGPL.

That said, it’s certainly possible to conceive of an LGPL-like license
with a specific exception for app store distribution. A closed-source
license is not the only solution.

I say this for the benefit of other future library authors, of course–Sam
has already chosen the license for SDL 1.3 and the only decision
contributors have to make is whether they’re comfortable with it.

GregoryOn Tue, 22 Mar 2011, Vittorio G. wrote:

On Tue, Mar 22, 2011 at 3:08 AM, Mason Wheeler wrote:

9

Gregory Smith wrote:

That said, it’s certainly possible to conceive of an LGPL-like license
with a specific exception for app store distribution. A closed-source
license is not the only solution.

If I recall correctly, the MPL is similar to the LGPL in that
one must share one’s modifications to the source code, but
without the LGPL’s constraints on mixing closed source and
static linking.

( http://www.mozilla.org/MPL/mpl-faq.html )

Regards,

Bill

10

Gregory Smith wrote:

That said, it’s certainly possible to conceive of an LGPL-like license
with a specific exception for app store distribution. A closed-source
license is not the only solution.

If I recall correctly, the MPL is similar to the LGPL in that
one must share one’s modifications to the source code, but
without the LGPL’s constraints on mixing closed source and
static linking.

( http://www.mozilla.org/MPL/mpl-faq.html )

Yep. I personally consider the MPL a much more useful license for
open-source projects than the GPL.>----- Original Message ----

From: Bill Kelly
Subject: Re: [SDL] [PATCH] FluidSynth backend for SDL_mixer

11

Many thanks for this. Most distros now offer a recent enough FluidSynth
and SDL_mixer 1.2.12 (which has your patch included), so I’m getting
nice MIDI quality now :slight_smile:

However, there’s a small problem. The audio’s volume is way too low.
FluidSynth has a default gain of 0.2. Apps using both MIDI and digital
audio have a problem, since when you turn up your speakers to make MIDI
audible, the other sounds become extremely loud.

Is there a way to raise the FluidSynth gain to something more sensible,
like 0.8?On 20/03/11 18:55, James Le Cuirot wrote:

Hello everyone,

Attached is a patch to add a FluidSynth backend to SDL_mixer. This
patch has been some time in the making but I now believe it is finally
ready.

12

Not exactly a game, but an application I wrote that runs games
(http://qtads.sourceforge.net). The games that run inside it decide on
the volumes. Thing is, even if I force the volume to MIX_MAX_VOLUME,
it’s still not loud enough, so a volume slider wouldn’t help much right
now. Not unless the internal maximum in the FS backend is raised. 1.0
or even 1.2 might be a better choice, since if it’s too loud, you can
always lower it, but if it’s too silent, you can’t do anything.On 04/03/12 18:57, James Le Cuirot wrote:

However, there’s a small problem. The audio’s volume is way too low.
FluidSynth has a default gain of 0.2. Apps using both MIDI and
digital audio have a problem, since when you turn up your speakers to
make MIDI audible, the other sounds become extremely loud.

Is there a way to raise the FluidSynth gain to something more
sensible, like 0.8?

I did experiment with this though I forget the exact results now. It
can go all the way up to 10 but I must have found 0.8 to be very loud,
otherwise I wouldn’t have set that as the maximum. Both of the games I
was trying allowed you to configure the digital audio and MIDI volumes
independently. In DXX-Rebirth, I prefer to have the music louder than
the effects so I set the music to 100% and the effects to about 60%. I
must admit that I didn’t measure the output but it probably will vary
between games and SoundFonts. What I heard did seem to reflect these
settings at least. Which game are you trying?

13

Not exactly a game, but an application I wrote that runs games
(http://qtads.sourceforge.net). The games that run inside it decide
on the volumes. Thing is, even if I force the volume to
MIX_MAX_VOLUME, it’s still not loud enough, so a volume slider
wouldn’t help much right now. Not unless the internal maximum in the
FS backend is raised. 1.0 or even 1.2 might be a better choice,
since if it’s too loud, you can always lower it, but if it’s too
silent, you can’t do anything.

That’s a good point so I don’t have a problem with it. Guys, please see
the attached patch which raises the maximum gain to 1.2.

Regards,
James
-------------- next part --------------
A non-text attachment was scrubbed…
Name: fluidsynth-gain.patch
Type: text/x-patch
Size: 906 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20120304/d31fddc6/attachment.binOn Sun, 04 Mar 2012 19:18:39 +0200 Nikos Chantziaras wrote:

14

Hi Nikos. I recognise you from the Gentoo community.

Many thanks for this. Most distros now offer a recent enough
FluidSynth and SDL_mixer 1.2.12 (which has your patch included), so
I’m getting nice MIDI quality now :slight_smile:

Thanks for the feedback. I wasn’t aware there had been a release. I had
plans for this new feature, mainly to discourage DXX-Rebirth and Return
to the Roots from distributing their music as digital audio, which is a
waste of bandwidth among other things. Unfortunately I ran out of time
for playing games. :frowning:

However, there’s a small problem. The audio’s volume is way too low.
FluidSynth has a default gain of 0.2. Apps using both MIDI and
digital audio have a problem, since when you turn up your speakers to
make MIDI audible, the other sounds become extremely loud.

Is there a way to raise the FluidSynth gain to something more
sensible, like 0.8?

I did experiment with this though I forget the exact results now. It
can go all the way up to 10 but I must have found 0.8 to be very loud,
otherwise I wouldn’t have set that as the maximum. Both of the games I
was trying allowed you to configure the digital audio and MIDI volumes
independently. In DXX-Rebirth, I prefer to have the music louder than
the effects so I set the music to 100% and the effects to about 60%. I
must admit that I didn’t measure the output but it probably will vary
between games and SoundFonts. What I heard did seem to reflect these
settings at least. Which game are you trying?

Regards,
JamesOn Sun, 04 Mar 2012 17:49:09 +0200 Nikos Chantziaras wrote:

15

This patch is in, thanks!On Sun, Mar 4, 2012 at 4:39 PM, James Le Cuirot wrote:

On Sun, 04 Mar 2012 19:18:39 +0200 Nikos Chantziaras wrote:

Not exactly a game, but an application I wrote that runs games
(http://qtads.sourceforge.net). The games that run inside it decide
on the volumes. Thing is, even if I force the volume to
MIX_MAX_VOLUME, it’s still not loud enough, so a volume slider
wouldn’t help much right now. Not unless the internal maximum in the
FS backend is raised. 1.0 or even 1.2 might be a better choice,
since if it’s too loud, you can always lower it, but if it’s too
silent, you can’t do anything.

That’s a good point so I don’t have a problem with it. Guys, please see
the attached patch which raises the maximum gain to 1.2.

Regards,
James

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org