search

dosbox-staging / dosbox-staging

DOSBox Staging is a modern continuation of DOSBox with advanced features and current development practices.
https://www.dosbox-staging.org/
Other
1.32k stars 157 forks source link

FluidSynth: Pans mostly to the left and sounds distorted/chorus and reverb settings have no effect #1525

Closed RavenMacDaddy closed 2 years ago

RavenMacDaddy commented 2 years ago

Are you using the latest Dosbox-Staging Version?

Different version than latest?

No response

What Operating System are you using?

Windows 11

If Other OS, please describe

No response

Relevant hardware info

CPU: AMD Ryzen 3600 | MB: MSI B450 Gaming Plus MAX | DAC: RME ADI-2 DAC | Speakers: EVE Audio SC205

Have you checked that no other similar issue already exists?

A clear and concise description of what the bug is.

What follows is used as it makes the mentioned issues very easy to hear and identify/reproduce;

Comparing FluidSynth using the SF2 soundfont found here, based on the Roland SC-55, using it on both DOSBox - both Staging and the DOSBox-X fork for reference testing - and the FluidSynth implementation in GZDOOM, running the same soundfont, there are some crucial noticed differences, or rather, issues only present in DOSBox.

To make a shortlist of what's observed with DOSBox:

Some examples, starting with DOOM being the easiest one since we're comparing to GZDOOM for reference:

Chorus and reverb off in GZDOOM with the aforementioned soundfont, it sounds pretty close to a real SC-55 playing back, or at least, the MIDI effects get turned off as expected and give what's close to the DOOM music sound, e.g. E1M1 - whereas with DOSBox there's still that panning to the left and reverb constantly throughout.

In Tyrian, many tracks sound like instruments are missing completely as not even certain melodies are playing at all in some songs - hey, maybe they actually are missing in the font, but combined with the issues observed I can't be sure that the font itself is to blame.

When testing with DOSBox-X as well for reference, the problems in this report seemed even worse, so not sure what's going on.

In Duke Nukem 3D, the same issues with playing sounds mostly on the left side and reverb always active is easily noticed, compared to for example using the built-in Microsoft GS Wavetable Synth (based on Roland SC) where things play as expected with stereo-imaging based in the center and no unnecessary reverb.

As described in the beginning, this is only to have a great example for troubleshooting - the FluidSynth implementation acts the same way regardless of the soundfont that's being used (basically it's more or less profound depending on which one you're using), the example simply makes it the easiest to identify the issues that are going on.

This is what comes to mind while writing this so far, will edit/update if I think of anything else.

Steps to reproduce the behaviour.

For DOOM:

  1. Let's start with the soundfont, as mentioned above, available here.
  2. GZDOOM for comparison with DOSBox is found here.
  3. To use a different soundfont than the one that's built-in to GZDOOM, go to the soundfont folder, add .bak to the one that's included, then place the soundfont from step 1 there and rename it to the name of the original soundfont; gzdoom.sf2
  4. The DOOM Shareware version is found is different places, but for example here on the Internet Archive, and here from the DOS Games Archive.
  5. For reference, GZDOOM only needs the WAD file.
  6. In both DOSBox and GZDOOM, confirm that FluidSynth is being used as the MIDI device in their respective configs/options (in GZDOOM, it's under something like Audio Options (you might need to choose Show all options since it's simplified as default) and then for the below, go to the sub-menu MIDI module options).
  7. Listen with stock settings in both DOSBox (auto for chorus and reverb) and GZDOOM - it should be a big difference already.
  8. Now turn off chorus and reverb in both and compare again - observe the resulting sound when comparing the apps.

For Tyrian:

  1. The game is available as freeware, and a great source is on GOG here.
  2. In the setup of Tyrian, select MIDI 330h since this is the default that's configured in DOSBox, and turn off SFX entirely for easy troubleshooting.
  3. Use the included Jukebox to listen to different tracks.
  4. An easy comparison - apart from the FluidSynth issues present described above - is with a real SC-55 playing the OST here.
  5. You can also compare to the default MIDI device Microsoft GS Wavetable Synth by setting default as the value in the DOSBox config.

Duke Nukem 3D:

  1. The game is found on the archive here; shareware and links to buy the full version.
  2. Once again, try with FluidSynth and compare to the default MIDI device Microsoft GS Wavetable Synth by setting default as the value in the DOSBox config.
  3. For reference, here's a real SC-55 playing the OST.

Your configuration

No response

Provide a Log

No response

Code of Conduct & Contributing Guidelines

kcgen commented 2 years ago

There are two issues at play:

So right now, comparisons against real SC-55 hardware are apples-to-known-oranges.

What about GZDOOM? This is a native port and they've made a pile of music improvements: https://github.com/coelckers/gzdoom/tree/master/fm_banks

An apples-to-apples comparison would be a DOS machine with GM sound card (and loadable or extractable soundfont) versus Staging + FluidSynth. where both the game and soundfont are identical. I understand several of Creative Labs Audigy and XFi soundfonts have been dumped, and those compare well.

Chorus and reverb are active - but I believe they're quite subtle. @GranMinigun has noted audible differences, and noted that some sounfonts are affected negatively (Staging uses a simple filename match and will log a warning if it's shutting off chorus and reverb when the SF2 is known to be affected).

We've discussed GS as well, amung many other issues (just for background context): https://github.com/dosbox-staging/dosbox-staging/issues?q=is%3Aissue+midi

RavenMacDaddy commented 2 years ago

What about GZDOOM? This is a native port and they've made a pile of music improvements: https://github.com/coelckers/gzdoom/tree/master/fm_banks

Tell me if I'm understanding this part correctly: Because of the work done on GZDOOM to improve its music playback capabilities, even if this incomplete SC-55 soundfont is being used by replacing the one that comes with GZDOOM, it will still play back decently thanks to those core music enhancements?

kcgen commented 2 years ago

I didn't go through the code, but reading those the fm_banks text files indicated they've augmented their music using a lot of "hybrid" techniques - like modifying OPL3 sounds to satisfy general standard instruments. Wording like:

This patch aims to remedy the "weak" default instruments to better match the Roland Sound Canvas, most notably the SC-55 and SC-88. ... Original set was not GM. Therefore, imported instruments are was organized to provide a proper GM set. Some instruments were a bit modified, some melodic instruments and percussions are was taken from Wohlstand's xg.wopn bank.

I'm not sure if there's a way to make GZDOOM behave in some kind of "legacy-only-mode" that strips away all of their improvements that let us get closer to an apple-to-apples comparison.

The best would be a DOS machine w/ Trevor402's SF2 loaded in an audio card, and see how that compares (if we're trying to compare SC-55 soundfont behavior in an apples-to-apples way).

RavenMacDaddy commented 2 years ago

Yeah, currently trying some different soundfonts - still mostly based on the SC-55 since that's the sound I'm after, being what most of the games from that time period were composed on etc. - and running with the default auto for chorus and reverb on those, your implementation is definitely doing considerably better, confirming it's mostly a soundfont issue.

EDIT: Something that I did notice though, playing with soundfont here, even when chorus and reverb are set to off, the volume of instruments often go up and down - while the playback itself sounds pretty good.

EDIT2: Same thing happens with Patch93's version and on the same spots on song 24 in Tyrian, so my guess is rather that it's the game's fault - it's too much of a coincidence.

Could this be related to the overall issues between FluidSynth and Roland based soundfonts, or even the frequencies being all over the place, like specifically mentioned in the issue you referred to?

kcgen commented 2 years ago

the volume of instruments often goes up and down

That's right; a midi song is essentially digital sheet music with even more information, like pitch bending and volume changes for each instrument as frequently as needed.

See the example section:

https://www.cs.cmu.edu/~music/cmsip/readings/davids-midi-spec.htm

Kappa971 commented 2 years ago

Hi. Unfortunately, those projects (https://github.com/Kitrinx/SC55_Soundfont and https://github.com/trevor0402/SC55Soundfont) no longer seem to be in development or in any case there have been no steps forward. All SC-55 soundfonts I've tried have problems (some instruments sound weird, volume unbalanced, etc) even though I haven't tried them with Fluidsynth. Unfortunately there is no emulator for the SC-55 (like MUNT for the MT-32). However, there is Sound Canvas VA, Roland's official VSTi that emulates the SC-8820 (supports the SC-55, SC-88, SC-88Pro, SC-8820 instrument maps) but it is expensive and doesn't emulate perfectly the 'SC-55, but still sounds better than soundfonts. If you search in Google you may also find it (I don't think I can say further here). Going back to Fluidsynth, from what I understand, you have only tried some SC-55 soundfonts. You could try this: 8MBGMSFX.zip If I'm not wrong, it should be one of the soundfonts available with the Sound Blaster Live!, the instruments are well balanced. PrBoom-plus also uses Fluidsynth, this I think might help @kcgen figure out if the problem is Fluidsynth or DOSBox Staging's implementation of Fluidsynth.

RavenMacDaddy commented 2 years ago

Thanks @Kappa971.

In fact, yesterday I did buy Sound Canvas VA and found some videos on how to set it up with SAVIHost, loopMIDI, and MIDIMapper for good measure to make sure that my preferred MIDI device is always used - couldn't be happier.

That's it to not derail the conversation, cheers and let's continue to make this project the best it can be.

Grounded0 commented 2 years ago

Roland SCVA is the most accurate software solution available for now for Roland SC-55.

Kappa971 commented 2 years ago

Thanks @Kappa971.

In fact, yesterday I did buy Sound Canvas VA and found some videos on how to set it up with SAVIHost, loopMIDI, and MIDIMapper for good measure to make sure that my preferred MIDI device is always used - couldn't be happier.

That's it to not derail the conversation, cheers and let's continue to make this project the best it can be.

Instead of SAVIHost I recommend Falcosoft MIDI Player. Going back to the issue, you could try the soundfont I shared with both DOSBox staging and PrBoom-plus (or Crispy Doom, Woof!, etc.) and see what results it produces. If it gives you the same problems in PrBoom-plus as well, I guess there is something to solve in Fluidsynth upstream (I think it's a good test, right @kcgen?)

marsej commented 2 years ago

Those with Sound Canvas VA might wish to return it and get either SC55mk2 or SCC1a if you need to hear like the game composers intended in games that were composed for those hardware units. (Important if you are implementing a soundfont or emulator I guess) (as said above by Kappa the VA doesn't emulate SC55 but a newer unit and voices and effects aren't always right)

2 Alternatives to implementing something like munt.

1) If the issue with SCVA boils down to how the midi input is mapped, it might be possible to create a translation table that modifies midi from games to set parameters in Sound Canvas VA such that they sound as if it was emulating SC55 instead of SC-8820.

2) A software could be made which takes midi input from games and as output plays corresponding flac/mp3 recordings made of those games. Then everyone would need to download recordings for each game they play or it would need to use a browser to play them from youtube (midi input, YT-URL output). Not ideal but such software can be implemented in matter of days. The problem with this clunky approach is that it doesn't work with iMUSE (Tie Fighter). X-Wing is fine with MUNT but Tie Fighter is better with SC55.

Kappa971 commented 2 years ago

Those with Sound Canvas VA might wish to return it and get either SC55mk2 or SCC1a if you need to hear like the game composers intended in games that were composed for those hardware units. (Important if you are implementing a soundfont or emulator I guess) (as said above by Kappa the VA doesn't emulate SC55 but a newer unit and voices and effects aren't always right)

I don't know in America or other parts of the world, but here in Italy they are available on Ebay at exaggerated prices (€ 200-300+). With all due respect to the game composers, I would never spend that money on a 30-year-old device :) In addition, Sound Canvas VA can be found in "less legal" ways.

  1. If the issue with SCVA boils down to how the midi input is mapped, it might be possible to create a translation table that modifies midi from games to set parameters in Sound Canvas VA such that they sound as if it was emulating SC55 instead of SC-8820.

Sound Canvas VA has no problem mapping SC-55 instruments when used with Falcosoft MIDI Player + LoopMIDI. Some instruments just sound slightly different from a real SC-55. The only "effect" not supported by SCVA is the instruments that are not cut when repeated quickly, used for example in Doom E1M1 (but I guess it was more of a limitation of the original SC-55).

RavenMacDaddy commented 2 years ago

@Kappa971 For what it's worth, the quality overall, tightness and ability to play sounds in quick succession improved dramatically when switching from SAVIHost to FalcoSoft MIDI Player.

kcgen commented 2 years ago

With a bunch of different external midi setups, an apples to apples comparison would be:

  1. run the same DOS game (not a port)

    • could be under real HW, PCem, DOSBox, etc..
    • "same", meaning exactly the same binary game files and configuration settings.

  2. Use the same general-MIDI soundfont in Staging+FluidSynth versus the external players for comparison (like Falcon Soft, etc..)

    • Ensure it's all general-MIDI across the board -(not some mix of Roland products, VSTis, or the DOS game configured for SC-55 or Roland-MIDI.)

Oh: I noticed if one searches for "vsti to sf2", a software tool and guide exists. Presumably to provide wider portability for VSTi owners.

arrowgent commented 2 years ago

i have all of those soundfonts everyone notes that replicating a real hardware solution to roland SC-55 is nearly impossible with software (fluidsynth or timidity, etc) but they are very good approximations with errors. unfortunate they have stopped releasing updates for those soundfonts

i was looking at this mt32-pi https://github.com/dwhinham/mt32-pi tool but again i think its mostly a software on hardware dac that tries to approximate the real hardware.

issue at hand that differences between ex: gzdoom and dosbox-staging with the same soundfont comparison dosbox-x to dosbox-staging? could be the differences in sound software? opl2, opl3, nuked, mame?

unfortunately im not an audiophile, i dont even play games or anything with headphones if youre looking to really test midi in different audio formats (mt32, cm32l, sf2) then get some dos midi players

https://github.com/dosbox-staging/dosbox-staging/issues/262

some dos midi software useful for testing? some midi players could be useful for exclusively testing midi (no extra game/sfx/etc, and lightweight)

http://dosmid.sourceforge.net/

also GSPLAY 1.0 version gsplay1.zip or labelled 1.1 i dont see any public sources, although many respositories list it as "freeware" so i wont post a link here not the same as gsplay v2.x free which is for windows

untested but others report using: megamid dos

these will only play midi and show you notes playing on the screen. you can then exit and switch sf2 or mt32 and replay the same midi i use both dosmid and gsplay. go a step further and record them as pcm .wav for comparisons (visual spectrum, audacity-fork)

ive also recorded DOOM using both of these: https://archive.org/details/SC55EmperorGrieferus https://github.com/trevor0402/SC55Soundfont/

lastly, dosbox-staging has a list ready for you! https://github.com/dosbox-staging/dosbox-staging/wiki/MIDI

arrowgent commented 2 years ago

heres some further batch script i can suggest which makes switching easier and faster in dosbox-staging:

MT32.bat

config -set "midi mididevice=mt32"
mixer MT32 66:66
config -set "mt32 model=mt32"
mixer /listmidi

CM32L.bat

config -set "midi mididevice=mt32"
mixer MT32 66:66
config -set "mt32 model=cm32l"
mixer /listmidi

FSMIDI.bat (set your path to sf2 file)

config -set "midi mididevice=fluidsynth"
mixer FSYNTH 69:69
config -set "fluidsynth soundfont=/usr/share/sounds/sf2/FluidR3_GM.sf2"
mixer /listmidi

FS2MIDI.bat

config -set "midi mididevice=fluidsynth"
mixer FSYNTH 69:69
config -set "fluidsynth soundfont=/usr/share/sounds/sf2/Trevor0402-SC-55.SoundFont.v1.2b.sf2"
mixer /listmidi

annnddd some quick midi play (edit your midi file and locations)

DOSMID.bat

mixer fm 33:33
cd midi
dosmid /MPU=330 /FULLCPU LEBLOOD9.MID
mixer fm 50:50
cd ..

GSPMID.bat

mixer fm 33:33
cd midi
cd GSP
GSPLAY LEBLOOD9.MID
mixer fm 50:50
cd .. ..
kcgen commented 2 years ago

Lots of great info, thanks for the help, @arrowgent! Will be curious how the comparisons turn out, if more folks can run them.

arrowgent commented 2 years ago

here is the GSPLAY.doc

G S P L A Y
MIDI File Player for DOS
Version 1.0 by Mark A. Fontana
Released May 29, 1996
Freeware

etc you can find it on archive

and DOSMID.txt

Copyright (C) 2014-2018 Mateusz Viste
All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this
   list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice,
   this list of conditions and the following disclaimer in the documentation
   and/or other materials provided with the distribution.

etc as noted http://dosmid.sourceforge.net/

just to cover all the bases

kcgen commented 2 years ago

Closing this.

  1. Title says "FluidSynth: Pans mostly to the left", however FluidSynth plays in balanced stereo on all platforms (Pi, Linux/x86, Windows, macOS x86, macOS arm64).

  2. Title says "FluidSynth: sounds distorted", however FluidSynth plays without distortion on all platforms (Pi, Linux/x86, Windows, macOS x86, macOS arm64).

  3. Title says "FluidSynth: chorus and reverb settings have no effect", however these control the magnitude of the effects when the DOS game or MIDI player applies chorus and reverb via SYSEX messages. In many cases, games applied these settings very conservatively, at most.

We have many MIDI users, and no one else has reported FluidSynth's built-in playback panned to the left or sounding distorted.

@RavenMacDaddy : if you still experience this, please provide recordings captured from DOSBox Staging or via your OS and a canned setup as zip file (demo game or midi player + embedded conf + embedded SF2 or download URL) so the team can compare apples-to-apples on their system and reproduce the issue.

johnnovak commented 11 months ago

So, I've noticed this now: there is definitely a difference between how FluidSynth sounds on 0.80.1 and our latest main version. In 0.80.1, the sounds are subtly or sometimes not-so-subtly panned to the left. In general, the sound is imbalanced and slightly "steering" to the left globally. It's more noticeable with some soundfont and game combinations than others.

Definitely very noticeable in the level 8 Descent soundtrack. Check my recordings on headphones (*-0.80.1.mp3 vs *-fixed.mp3 which is current main):

https://archive.org/details/dosbox-staging-v0.81.0-fluidsynth-fixes

@kcgen any ideas? I've checked the commit logs of midi_fluidsynth.cpp, but nothing jumps out. I did check the FluidSynth changelog too but could not see anything promising. My guess is the FluidSynth folks "silently" fixed this or something, and we just got the fix for free by upgrading. 🤷🏻

Now, how to present this in our release notes... "FluidSynth is now fixed... somehow, we have no idea! But... hey, rejoice! " 😅

kcgen commented 11 months ago

Nothing I know of either; always nice getting free fixes from dependencies!

Looking back at the wrap syncs commits, 0.80.1 would have been using 2.3.0, and we're now shipping 2.3.3-2.

These were bumped in commits:

I remember most of these had at least one audible fix.. but I don't remember any mention of panning issues being fixed.

johnnovak commented 11 months ago

Nothing I know of either; always nice getting free fixes from dependencies!

Looking back at the wrap syncs commits, 0.80.1 would have been using 2.3.0, and we're now shipping 2.3.3-2.

These were bumped in commits:

* [d76e6ba](https://github.com/dosbox-staging/dosbox-staging/commit/d76e6bad431796faf8bab51c148c1cb8a03e6f3b) 10 weeks ago to 2.3.3-2

* [6644cf2](https://github.com/dosbox-staging/dosbox-staging/commit/6644cf23cc86e754f8727e056da6297e66e9a936) 5 months ago  to v2.3.3-1

* [356f061](https://github.com/dosbox-staging/dosbox-staging/commit/356f06172f9e531d0628f502f27d349dcccce91a) 8 months ago to v2.3.2

* (0.80.1's) [a2d157d](https://github.com/dosbox-staging/dosbox-staging/commit/a2d157d45b2d2958c21452971b552aaa95200015) 1 year, 2 months ago to 2.3.0

I remember most of these had at least one audible fix.. but I don't remember a panning issue.

Yeah, I can't see anything that could've fixed this in the changelogs still, and I'm not gonna go through all their commits. I'll just mention it in the notes that now FluidSynth is now "better" or something 😄

Grounded0 commented 11 months ago

Changed closed signal to completed as this was fixed in a FluidSynth update.

johnnovak commented 11 months ago

Changed closed signal to completed as this was fixed in a FluidSynth update.

Fair call. I spent like an hour trying to figure out what fixed it. Surely it could be eventually figured out, but I couldn't bother. If it's indeed a FS update that fixed it as we think, that's slightly troublesome because they did not advertise this explicitly in their changelog. Maybe they're not even aware they fixed some issues, dunno. Meaning regressions can happen the same way, unannounced, because they might have some quality assurance problems there... We'll see with time, I guess 🤞🏻

Grounded0 commented 3 months ago

Fixed in FluidSynth 2.3.6:

This should be the final fix for the left panning issue. I hope we get this release of FluidSynth for 0.82.0. FluidSynth has got significantly more robust after it was selected as the MIDI backend for Wine.

johnnovak commented 3 months ago

Fixed in FluidSynth 2.3.6:

This should be the final fix for the left panning issue. I hope we get this release of FluidSynth for 0.82.0. FluidSynth has got significantly more robust after it was selected as the MIDI backend for Wine.

vcpkg only has 2.3.5 currently: https://vcpkg.io/en/package/fluidsynth

Let's not screw around with a big dependency upgrade before the release. We'll upgrade after 0.82.0 is out. 99% of people won't notice these minor issues, and the current FS version works well enough.

Grounded0 commented 3 months ago

I haven't noticed this issue after 0.81.0 so guess we're safe with what we got. This is the final fix for it for builds with single precision floats (FluidSynth default is double precision floats).