Dosbox-x: Suggestion: Update mt32emu to 2.3.0

Created on 24 Dec 2017  路  25Comments  路  Source: joncampbell123/dosbox-x

I think to add this issue when I want DOSBox-X update mt32emu to 2.2.0,
but mt32emu 2.3.0 has released today.
https://github.com/munt/munt/releases/tag/libmt32emu_2_3_0

Older MT-32(ROM ver 1.07) emulation has almost fully accurate since munt 2.2.0.
you can use DOSBox-mt32-patch/dosbox-SVN-r4025-mt32-patch.diff in this archive.

done enhancement audio

Most helpful comment

All 25 comments

I'm going to try and test the mt-32 emu with munt. I will post back if I can get it to work.
In the meantime, here are some outstanding mt-32 reports which should be rolled into one and or closed:
https://github.com/joncampbell123/dosbox-x/issues/310
https://github.com/joncampbell123/dosbox-x/issues/115

OK so I tested it. mt-32 currently does not work with munt here on Windows 64 bit.
I was testing with the Legend of Kyrandia game which has mt32 support in it's setup routine using munt_2_3_0 pre-compiled from Sourceforge. If anyone has a recommendation of a mt32 demo application to try, please chime in.

The patch mentioned by @basic2004 is here looks like it fixes https://github.com/joncampbell123/dosbox-x/issues/322 looking at: https://github.com/joncampbell123/dosbox-x/blob/6091cfde92caf4e18f734c7d558dc3876eb2bcce/src/gui/midi_mt32.h#L104

Could this patch be evaluated and merged please?

I looked into this and thought it would be more trivial than it is. The patch does not merge cleanly.
The two projects (dosbox-x and munt) use different build systems. munt uses cmake and dosbox-x uses autoconf/automake.
cmake and autoconf are two different ways of doing the same thing.
Dosbox-x has had munt's library shoehorned into it's build. This makes it difficult to import newer versions of munt into dosbox-x unless you were the person who merged the munt library into dosbox-x.
There are a large number of changes in the newer version of munt. However, when trying to merge the new code, I just found circular header dependencies.

If your interested in hacking it into compile with DOSBox-X's codebase, that's fine, otherwise don't worry about it. I could pick a future weekend to try that.

It couldn't be any worse than the work of incorporating FM synthesis code from Neko Project II, considering NP2 emulation works very differently from DOSBox-X.

So, I got it to build...
https://github.com/heydojo/dosbox-x-midi
I need to test if this fixes the issue at hand but I have stuff to do IRL, so I'll just leave this here.
@joncampbell123 I'll shoot you over a pull request in a few days if testing works out.
Also, neither mt32 or fluidsynth emu were enabled in the build config for VS2015 in master.

So, I was able to port libmt32emu 2.3.0 to Dosbox-X. The issue, (I think) was that I was trying to merge the patch the munt guys had created for Dosbox with what was already in the Dosbox-X tree. The code from the munt guys uses a new service interface which operates above the synth code to deal with things like; people who want to change the partials once the emulation has started (I guess.) You can still interface with the synth directly as per the way Dosbox-X is doing it but you don't get to tweak some of the nice extra features which have been added. I was able to port the romdir option too.
For lack of a DOS MT32 program to test the code with, I can't confirm if the code 100% works but it builds on Windows, loads the byte code, opens and closes the mixer without crashing.

I found out after quite a bit of research there aren't many games which supported the MT32 but there were a lot of games which claimed MT32 support which either didn't add it or it did not work.
So it's difficult to test.

This is working in my fork. Recommended to set:
mt32.thread=on
If anyone is looking to pull the changes into Dosbox-X.

If you submit a pull request I'll happily merge it into DOSBox-X.

A good example that I was given is the game "Lure" which supports the MT-32, though only if you set the cycles count low enough for it's MPU-401 detection to work.

You'll know it's working if the game is able to render audio dripping noises and a door creaking when the game starts in the dungeon. If it sounds like crap FM synth noises, it didn't detect the MPU-401.

Better test example:
Space Quest 3. The intro music sounds night and day better with MT32. MT32 has to be selected using the install program INSTALL.EXE first.
Without working MT32 emulation, the Windows MIDI device will playback the MT32 data and it sounds meh :/

@heydojo @joncampbell123 Hi, I'm wondering if PR was ever raised/merged updating munt version bundled with DosBox-X? Actually I'm wondering what version of munt is being included currently in DosBox-X master branch? I wasn't able to spot any "readme" or "version" file inside mt32 folder :-(.

I'll try MT32 with VS2017 again, see if it works.

I'm not sure what version of munt is in DOSBox-X, I only know it's what was in Daum's branch sometime 2014 or in DOSBox SVN when I first started this in 2011.

I'll try MT32 with VS2017 again, see if it works.

I'm not sure what version of munt is in DOSBox-X, I only know it's what was in Daum's branch sometime 2014 or in DOSBox SVN when I first started this in 2011.

Daum's munt had a custom mmath.h that requires SSE2 to work. This limits it to x86 platforms..
The mt32emu upstream had a generic mmath.h.

I was able to add working MT32 for Windows by adding a #define C_MT32 1 to vs2015config.h

@joncampbell123 I guess your change is a fix for issue #827 rather than this one?

I tried to upgrade mt32emu to 2.3.0 and succeeded. However, although it had better sound, newer mt32emu uses a lot more CPU than the bundled one since DOSBox Daum (from about 2013?).

So they made it that much more accurate then!

Also it might be that optimizations are not turned on by default in 2.3.0. Still it'll be interesting to check how does new mt32emu copes on low power systems like RPi2. IIRC mt32emu is mostly single threaded so question would be if a single core performance of RPi2 is enough for new mt32emu.

I don't know what version of munt is currently integrated into DOSBox-X, but DOSBox ECE just released a new version with the latest munt 2.4.0
https://www.vogons.org/viewtopic.php?p=895941#p895941

@rderooy It is indeed not very clear the exact version of the previous MUNT in DOSBox-X. But since the copyright year apparently referred to 2013, it must be a very old version. In any case, I have already updated MUNT to 2.4.0 in the repository. Please check out the latest code.

@Wengier, this is just a personal request so feel free to ignore. I would find it very helpful if you could link to the change when you've mentioned already implementing it.

For example, in this case, the only open PR is the libslirp change, and likewise I've scrolled through the last month's worth of closed PRs (given "_already implemented_" implies the past-tense), however there's zero mention of Munt in those descriptions either.

I know this is more work, but I think it would help those interested in seeing said changes (or at the least take any guesswork out of it). Much thanks!

@kcgen Also, I will try to link to the actual commit when I implement a change in the future too. Thanks for the suggestion.

Thank you @Wengier!

Thanks to update, @Wengier
I forgot this issue long time, I'm sorry.
You can close this issue because I confirmed this.

I will close the issue for now. Thanks for making the suggestion to update the library.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

joncampbell123 picture joncampbell123  路  14Comments

joncampbell123 picture joncampbell123  路  7Comments

sduensin picture sduensin  路  7Comments

jadasse picture jadasse  路  19Comments

inukaze picture inukaze  路  8Comments