VOGONS

Common searches


First post, by mgiuca

User metadata
Rank Newbie
Rank
Newbie

Hi,

I was getting sick of having to manually start up FluidSynth and connect DOSBox to it (through ALSA, on Linux, for example). So I got around to writing a FluidSynth driver for DOSBox, so it can directly send MIDI commands to FluidSynth via its own API. For those who don't know what this is, it's a MIDI synthesiser that turns DOSBox's MPU-401 MIDI commands into sound.

Its usage is pretty simple, you just set this in the [midi] section:

mididevice=fluidsynth
midiconfig=audio_driver:soundfont

for example, on Linux, I might have:

mididevice=fluidsynth
midiconfig=pulseaudio:/usr/share/sounds/sf2/FluidR3_GM.sf2

Then, all DOSBox MPU-401 games will automatically produce sound without having to start up any extra software. (I don't have many MPU-401 games, but King's Quest VII requires some external MIDI synth, and this works for that game.)

I have found a year-old forum post here with a similar patch, that doesn't appear to have been accepted. So perhaps I am wasting my time, but since I wrote my patch, I may as well post it here. My patch looks simpler than that one -- it doesn't create a whole event structure, it just passes the messages directly to FluidSynth API calls. The whole driver is 137 lines.

I am maintaining the patch in a Bazaar branch on Launchpad here. The full patch is here: download. I am also attaching the patch to this post.

I am not sure how hard it is to get MIDI games working in DOSBox under Windows -- perhaps someone can explain what the process is like. But under Linux, it is quite a pain if you don't have a hardware synth, requiring that you set up a separate MIDI synth. Hopefully, this patch will make it much easier to get MIDI games working. Unfortunately, it still requires that the user configure the driver name and specify the path to the soundfont, but at least that can be done on a once-off basis.

Attachments

  • Filename
    fluidsynth.diff
    File size
    10.67 KiB
    Downloads
    208 downloads
    File comment
    Patch to add FluidSynth driver to DOSBox.
    File license
    Fair use/fair dealing exception

Reply 1 of 9, by mgiuca

User metadata
Rank Newbie
Rank
Newbie

A quick update: made it so the FluidSynth driver is tried LAST, instead of FIRST.

This page will always contain a link to the up-to-date patch.

Attachments

  • Filename
    fluidsynth.diff
    File size
    10.74 KiB
    Downloads
    209 downloads
    File comment
    Updated diff.
    File license
    Fair use/fair dealing exception

Reply 2 of 9, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Thanks for your effort. If I had any say in Dosbox I'd accept this patch 😉

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox

Reply 5 of 9, by VileR

User metadata
Rank Oldbie
Rank
Oldbie

I wouldn't assume that it was rejected, as there hasn't been an official DOSBox release since you put up the patch.

Don't know why it wasn't moved to the patches forum, though - would be nice to have it where more people would notice and get the chance to test.

EDIT: ah, there it is. :)

Reply 6 of 9, by Ocean112

User metadata
Rank Newbie
Rank
Newbie

I've been using ykhwong's build of dosbox which I'm assuming includes this patch. Is there anyway to set the gain of fluidsynth in the config options? Looking at the code on the lauchpad I can't see it. If it isn't, adding in an option to set the gain in the conf file with the rest of the midi options would be great. Especially as all soundfonts aren't recorded at the same level. If I'm being an idiot and a gain option is already included, please inform me as to how. I saw in one of the old fluidsynth topics where a setting might have been implemented as synth.gian=* but I tried that to no success. Short of re-doing the soundfont I would like to use and upping the base magnitude all around I don't see any other way to go about it, other than a volume control attached to the entire midi section.

Reply 9 of 9, by Ocean112

User metadata
Rank Newbie
Rank
Newbie

That's to be expected really, as most soundfonts, while having a common recording amplitude inside each "font", they can differ greatly between them. Each soundfont would have a different "best" gain setting associated with it (to match the volume of the emulated digital audio). It just depends on how and who sourced the samples. (and how they prepared them for the pack) Thanks for the help though.

EDIT: As a side-note though, I had to make the 20120701 build large address aware for the SGM and Crisis soundfonts that I tried work. Probably something everyone's already aware of but if you don't well, there you are.