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?

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.

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.

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:

1fluid.driver          = default
2fluid.soundfont       = ..\FluidR3_GM.sf2
3fluid.soundfont2     = ..\FluidR3_GS.sf2
4fluid.samplerate      = 48000
5fluid.gain            = .6
6fluid.polyphony       = 256
7fluid.cores           = 4
8fluid.periods         = 8
9fluid.periodsize      = 512
10fluid.reverb          = yes
11fluid.chorus          = yes
12fluid.reverb,roomsize = .61
13fluid.reverb.damping  = .23
14fluid.reverb.width    = .76
15fluid.reverb.level    = .57
16fluid.chorus.number   = 3
17fluid.chorus.level    = 1.2
18fluid.chorus.speed    = .3
19fluid.chorus.depth    = 8.0
20fluid.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.

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:

1char fluidaudiodriverused[256];
2
3memset(fluidaudiodriverused, '\0', 256);
4fluid_settings_copystr(settings, "audio.driver", fluidaudiodriverused, 256);
5LOG_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.

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.

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.

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?

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:

1cmake -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.

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.

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.

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.

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?

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

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.

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.

Hmm, the forum won't allow any attachments.

We fixed this for you.

On Fedora (33 currently) Linux, when running DOSBox ECE, (or the latest DOSBox-X from git), which includes fluidsynth support. And running anything that outputs midi sounds, I experience a lot of crackles and pops in the audio.

An example of this is canyon.mid when running WfW3.11 in DOSBox. But when I play back that same file directly on the desktop with the default totem media player (gstreamer1-plugins-bad-free-fluidsynth.x86_64 installed), it plays perfectly fine.

The same crackles and pops happens with any game that outputs general midi. Using a different soundfont does not change the issue.

1$ ls -l /usr/share/soundfonts/default.sf2 
2lrwxrwxrwx. 1 root root 14 Jan 28 19:46 /usr/share/soundfonts/default.sf2 -> FluidR3_GM.sf2
3$ rpm -q --whatprovides /usr/share/soundfonts/default.sf2 
4fluid-soundfont-gm-3.1-22.fc32.noarch
5$ rpm -q fluidsynth
6fluidsynth-1.1.11-7.fc32.x86_64

My dosbox config contains:

1[midi]
2mididevice=fluidsynth
3fluid.driver=pulseaudio
4fluid.soundfont=/usr/share/soundfonts/default.sf2

*update*

running

1$ fluidsynth -i -a pulseaudio WINDOWS/CANYON.MID 
2FluidSynth runtime version 1.1.11
3Copyright (C) 2000-2018 Peter Hanappe and others.
4Distributed under the LGPL license.
5SoundFont(R) is a registered trademark of E-mu Systems, Inc.
6
7fluidsynth: Using PulseAudio driver
8fluidsynth: warning: Failed to set thread to high priority
9fluidsynth: warning: Failed to set thread to high priority
10fluidsynth: warning: Failed to pin the sample data to RAM; swapping is possible.

Works perfectly fine, so should not be a pulseaudio vs jack issue.

Going through the official fluidsynth settings, I noticed that this patch uses default values for "periods" and "periodsize" that are actually meant for Windows.

For Linux and MacOSX you should therefore add the following lines to your [midi] section:

1fluid.periods=16
2fluid.periodsize=64

Those are the default values normally when using FluidSynth on Linux or MacOSX, but unfortunately this patch fixes them to the Windows default of 8 and 512 respectively.

Changing the values results in clearer MIDI playback on my Linux system.

FYI, I submitted a patch to DOSBox-X, which was accepted, to change the default fluid.periods and fluid.periodsize values for non-windows systems to their proper values. It would be good if DOSBox ECE or any other forks that have the FluidSynth patch integrated also apply it for proper playback on Linux and Mac OS X.

https://github.com/joncampbell123/dosbox-x/co … edea4fa433dc609

I'll add it to one of the next updates of ECE. Thanks!