VOGONS


Fluidsynth soundfont patch

Topic actions

Reply 60 of 75, by Kisai

User metadata
Rank Member
Rank
Member
Yesterplay80 wrote:
Kisai wrote:

Hmm I used the most recent ECE based on 4259 and noticed that when the internal recording is used, the midi rendered output from fluidsynth is now missing.
...
In the old fluidsynth dosbox patched versions, it simply rendered the music into the audio buffer like the MT32 driver does.

Definitely not, your memory must play tricks on you there. Fluidsynth in ECE always worked via an external dll file, therefore the MIDI sound could never be recorded directly in the avi while using the built-in recording function. Either you used an external recording tool like OBS, or you used another MIDI playback option or even another DOSBox build before.

I know I used ECE at some point, I just normally don't use Fluidsynth with recordings since the games I play have the MT32 tracks, using fluidsynth on those games ends up with missing sounds. Anyway, which version of Fluidsynth are you using now? There's no version in the dll file. Are you still using 1.1.6?

Reply 61 of 75, by Yesterplay80

User metadata
Rank Member
Rank
Member
Kisai wrote:

Anyway, which version of Fluidsynth are you using now? There's no version in the dll file. Are you still using 1.1.6?

Yes, I couldn't get any never version working with the patch I'm using.

My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)

Reply 62 of 75, by Kisai

User metadata
Rank Member
Rank
Member
Yesterplay80 wrote:
Kisai wrote:

Anyway, which version of Fluidsynth are you using now? There's no version in the dll file. Are you still using 1.1.6?

Yes, I couldn't get any never version working with the patch I'm using.

So I went through all my individual patches on the weekend to see if I could apply all of them to the current version of dosbox. Compiled statically with Visual Studio 2019.

I spent a while trying to figure out why this version didn't sound like ECE, and then I noticed that there are settings completely omitted in ECE's source code, as the fluidsynth patches don't match.

The two features this version has that ECE does different for the fluidsynth patch is that this version lets you load two SF2 files (the SF2 I'm fond of using has a GM and and GS bolt-on to it) and it sends the output through dosbox so the volume can be adjusted by the mixer, or recorded.

With that said it plays louder than ECE does given the same .conf file.

Attachments

Reply 63 of 75, by Kisai

User metadata
Rank Member
Rank
Member

I scratched my head about this a bit more, but it turns out putting the callback back in was more trivial than compiling fluidsynth. It can't be used simultanously however. So either you run the midi audio "default" through dosbox, or you run it in a separate directsound/sdl2 thread. The build of fluidsynth1.1.6-noglib I'm using I backported the SDL2 driver and the directsound driver.

The binary attached supports having "dsound, sdl2, or default" as the fluidsynth driver.
example:

fluid.driver          = default
fluid.soundfont = ..\FluidR3_GM.sf2
fluid.soundfont2 = ..\FluidR3_GS.sf2
fluid.samplerate = 48000
fluid.gain = .6
fluid.polyphony = 256
fluid.cores = 4
fluid.periods = 8
fluid.periodsize = 512
fluid.reverb = yes
fluid.chorus = yes
fluid.reverb,roomsize = .61
fluid.reverb.damping = .23
fluid.reverb.width = .76
fluid.reverb.level = .57
fluid.chorus.number = 3
fluid.chorus.level = 1.2
fluid.chorus.speed = .3
fluid.chorus.depth = 8.0
fluid.chorus.type = 0

The main purpose to having the callback is so that you can use dosbox's internal recording mechanism. It also saves needing to figure out how to compile fluidsynth's drivers on operating systems that might not have it.

20190926 edit: Made some minor revisions to the compiled binary's fluidsynth library.

Attachments

  • Filename
    _dosbox-fluidsynth-20190926_dosboxece.diff
    File size
    18.77 KiB
    Downloads
    13 downloads
    File comment
    Slightly more extensive patch against ECE that affects the mt32 and dosbox.cpp to create fluidsynthoptions.h
    File license
    Fair use/fair dealing exception
  • Filename
    fluidsynthoptions.h
    File size
    3.68 KiB
    Downloads
    10 downloads
    File comment
    fluidsynthoptions.h 20190926
    File license
    Fair use/fair dealing exception
  • Filename
    midi_fluidsynth.h
    File size
    6.89 KiB
    Downloads
    9 downloads
    File comment
    midi_fluidsynth.h 20190926
    File license
    Fair use/fair dealing exception
  • Filename
    20190926-dosbox-074-3-r4259-sdl2-opendml-mt32-fluidsynth(c)-nukedopl.7z
    File size
    1.31 MiB
    Downloads
    12 downloads
    File comment
    dosbox-074-3-r4259 , sdl2, opendml with capture cutter, mt32, fluidsynth(c), nukedopl.
    File license
    Fair use/fair dealing exception

Reply 64 of 75, by Grunt

User metadata
Rank Newbie
Rank
Newbie
Kisai wrote:

I scratched my head about this a bit more, but it turns out putting the callback back in was more trivial than compiling fluidsynth. It can't be used simultanously however.

Hey man, thanks a lot Kisai. Finally I was able to hardcode Fluidsynth part of patch into SVN DOSBox (I do have my custom version) and it finally works. Suprisingly. Now I've captured videos with nice MIDI synth directly rendered into them.
I have only one question:

char fluidaudiodriverused[256];

memset(fluidaudiodriverused, '\0', 256);
fluid_settings_copystr(settings, "audio.driver", fluidaudiodriverused, 256);
LOG_MSG("MIDI:fluidsynth: Audio driver: %s", fluidaudiodriverused);

What is this? 256 characters long buffer for what exactly?

Nevertheless, it works and it's just as you said: It is more trivial to redirect output into dosbox mixer than compile operational FluidSynth library. At least under MinGW enviroment. There is a lightweight version of FluidSynth just for this purpose: FluidSynth-Lite with all sound drivers removed, all external dependencies on GTK + removed. libfluidsynth.a already prepared in my msys folder. Unfortunatley also with different / newer API.

Now I am scratching my head. When it's so easy to get synth stream back into main mixer why hasn't been this already implemented into mainline version of DOSBox? It is a nice feature to have.

Reply 65 of 75, by realnc

User metadata
Rank Member
Rank
Member
Grunt wrote:

Nevertheless, it works and it's just as you said: It is more trivial to redirect output into dosbox mixer than compile operational FluidSynth library. At least under MinGW enviroment. There is a lightweight version of FluidSynth just for this purpose: FluidSynth-Lite

Please don't use that. It's an old version of fluidsynth and there have been major improvements to fluidsynth since then, including custom sound output support.

Reply 66 of 75, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

FluidSynth Lite is Vista+. ScummVM had to use an earlier version of it for it to work on XP. If DOSBox were to use it then would only make sense when it switches to SDL2 since that still supports XP.

ScummVM 2.1.0 for Win95/98 Anyone tried it yet?

What's odd is that Fluidsynth 2.1 mentions XP and earlier Operating systems being tested.

DOSBox Compilation Guides
DosBox Feature Request Thread
PC Game Compatibility List
How To Ask Questions The Smart Way
Running DRM games offline

Reply 67 of 75, by Grunt

User metadata
Rank Newbie
Rank
Newbie
realnc wrote:

Please don't use that. It's an old version of fluidsynth

You mean fluidsynth 1.1.6? And are you aware that I'm currently using even older version of fluidsynth? OK, do you know any better option?

Reply 68 of 75, by realnc

User metadata
Rank Member
Rank
Member
Grunt wrote:
realnc wrote:

Please don't use that. It's an old version of fluidsynth

You mean fluidsynth 1.1.6? And are you aware that I'm currently using even older version of fluidsynth? OK, do you know any better option?

You can build a minimal version of Fluidsynth (2.1.0 currently) that does depend on audio drivers or SDL. For example, this will give you a static libfluidsynth library you can link directly into the dosbox executable:

cmake -DBUILD_SHARED_LIBS=OFF -DCMAKE_BUILD_TYPE=Release -Denable-alsa=OFF -Denable-aufile=OFF -Denable-dbus=OFF -Denable-dsound=OFF -Denable-ipv6=OFF -Denable-jack=OFF -Denable-ladspa=OFF -Denable-lash=OFF -Denable-libinstpatch=OFF -Denable-libsndfile=OFF -Denable-midishare=OFF -Denable-network=OFF -Denable-oss=OFF -Denable-portaudio=OFF -Denable-pulseaudio=OFF -Denable-readline=OFF -Denable-sdl2=OFF -Denable-systemd=OFF -Denable-threads=ON -Denable-waveout=OFF -Denable-winmidi=OFF

This is what I use to ship a project of mine as a single exe on Windows. It still needs glib, but I have that build statically as well along with everything else (with the only exception being libVLC). Even a small soundfont is built-in into the exe so it just works.

Reply 69 of 75, by Kisai

User metadata
Rank Member
Rank
Member
realnc wrote:
Grunt wrote:
realnc wrote:

Please don't use that. It's an old version of fluidsynth

You mean fluidsynth 1.1.6? And are you aware that I'm currently using even older version of fluidsynth? OK, do you know any better option?

You can build a minimal version of Fluidsynth (2.1.0 currently) that does depend on audio drivers or SDL. For example, this will give you a static libfluidsynth library you can link directly into the dosbox executable:

To be fair the version of fluidsynth I use, is actually the last 1.x series with the glib content stripped back out to how it worked in 1.1.6 . 2.x actually removes functionality which is why I didn't use it. If you're on Linux, feel free to use glib. If you're on Windows and using VC++ like I do, glib is annoying to get to compile, and adds a needlessly large shared library when fluidsynth uses almost no functionality from it. 2.x may work.

Anyhow, the compilation issues between windows and *nix are only complicated with Fluidsynth 2.x, but that's not in DosBOX, it's it Fluidsynth. Fluidsynths dependance on glib makes it potentially break future versions of anything it's compiled into, because that already happened with VNC.

Reply 71 of 75, by dreamer_

User metadata
Rank Member
Rank
Member
realnc wrote:

I thought package managers like vcpkg made these issues a thing of the past. If you want a VC++ glib, you just install it with vcpkg and it's there.

DOSBox SVN is not compatible with vcpkg, solution files need to be manually fixed to make it compile. dosbox-staging fixes it - you can use vcpkg packages and it will work OOTB.

| ← Ceci n'est pas une pipe
dosbox-staging

Reply 72 of 75, by Yesterplay80

User metadata
Rank Member
Rank
Member

I'd like to give your updated patch a try in ECE, Kisai.So, besides the patch and GLIBless fluidsynth source files, what would I need? Is the backporting you mentioned done in the patch or would I have to make changes to the fuidsynth source beforehand? If so, which changes are required?

My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)

Reply 73 of 75, by realnc

User metadata
Rank Member
Rank
Member

For the fluidsynth 2.1 support that I've added to a libretro dosbox core I'm currently working on, having fluidsynth output audio is not necessary. Instead you can make it render audio directly in the dosbox mixer buffer using fluid_synth_write_s16(). I added an FSYNTH dos mixer channel (like the MT32 mixer channel). This gets rid of having to build fluidsynth with audio driver output support. Maybe this can be adapted for this patch as well:

https://github.com/realnc/dosbox-core/blob/li … _fluidsynth.cpp

Reply 74 of 75, by Kisai

User metadata
Rank Member
Rank
Member
Yesterplay80 wrote on 2020-02-10, 11:04:

I'd like to give your updated patch a try in ECE, Kisai.So, besides the patch and GLIBless fluidsynth source files, what would I need? Is the backporting you mentioned done in the patch or would I have to make changes to the fuidsynth source beforehand? If so, which changes are required?

OK, so basically consider fluidsynth , and the dosbox fluidsynth patch as two separate things.

For Fluidsynth itself, I've been backporting pieces from 1.1.6+ (eg including pieces from 2.x) that I statically compile, since I use visual studio the .lib files I have might not work with your setup, but I can just zip the entire thing up if you want it.

The patch for dosbox is earlier in the thread. The _dosbox-fluidsynth-20190926_dosboxece.diff is against ECE's files IIRC at the time. So unless there have been extensive changes since, it should still work.

The attached file is a copy of what I currently use for the fluidsynth library, including the 32-bit and 64-bit static libs. I've never made changes to the autotools or cmake files so they probably will still work, but YMMV.

Filename
fluidsynth-1.1.6-noglib-usewithdosbox.7z
File size
1.11 MiB
Downloads
1 download
File license
GPL-2.0-or-later

I believe fluidsynth or the mt32 library uses the soxr library, but the version I have compiled of that is vanilla, and that's a compiler directive. So you shouldn't need it.

Last edited by Stiletto on 2020-02-14, 18:39. Edited 1 time in total.
Reason: added attachment