VOGONS


MT-32 emulation woes

Topic actions

First post, by TeaRex

User metadata
Rank Member
Rank
Member

Hello to all,

I found out that the existing Munt download on sourceforge (0.1.3), while sounding very nice on very slow pieces, stutters noticably on faster pieces of music with DOSBox on my netbook system. This happens even when running just 3000 cycles in dynamic core, while this netbook is able to do more than 30000 cycles without sound problems when the Yamaha S-YXG50 soft-synth is providing MIDI instead.

I'm looking for a solution, and I've had the following rough ideas:

1.) Download the latest Munt code CVS and compile it myself with the better compiler of VC++ 2010 and more smart optimization switches, especially SSE2. No luck so far after several hours of to-and-from with VC++ Express 2010.

1.5.) Do the same with the source of the released Munt 0.1.3. No more luck than 1.) above, so far, although I didn't try as hard on this one.

2.) Build DOSBox with the built-in MT-32 ala gulikoza. However his source is currently getting a bit old (mid 2009 IIRC). Also I already have the standard DOSBox cvs all set up for building in VC++ 2010, so.... I wonder, is the MT-32 patch in the gulikoza build (or another MT-32 patch for DOSbox) available separately anywhere? Like as a .diff or so that I could stick into the newest DOSBox with a bit of manual work?

3.) How about somebody else having a working Munt CVS set-up that's compilable for a newer VC++, 2008 or 2010? Would you be willing to zip up your source tree and mail it to me, maybe? Or would this draw down the wrath of Roland on us?

Or am I completely barking up the wrong tree here, and MT-32 emulation is simply so much more complicated than Yamaha XG that it's beyond the capabilities a 1,6 GHz Intel Atom netbook?

Thanks a lot in advance for your consideration!

tearex

Reply 1 of 8, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

0.1.3 is ancient. It has been mostly rewritten at least 2 times since, AFAIK. You can take src/gui/midi_mt32.h from my sources (this is the dosbox-munt interface) and put it into some fresh svn checkout (add #include "midi_mt32.h" into midi.cpp after /* Include different midi drivers, lowest ones get checked first for default */). The rest of the munt files are mostly unmodified so just dump them inside the gui and include directories. After some Project fiddling it should compile 😀

edit: oh, you're running on atom? That's a though one, yes MT32 is very demanding, later versions even more...

http://www.si-gamer.net/gulikoza

Reply 2 of 8, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

yup, my first thought when reading "on my netbook system"! Seriously, you should probably not use MUNT or any other way of doing MT32 emulation while also running Dosbox. These are two demanding emulators (even though the games that benefit from MT32 are not the most demanding DOS games). On desktop system or a strong laptop, yes, on a netbook maybe not...

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 3 of 8, by robertmo

User metadata
Rank l33t++
Rank
l33t++

gulikoza's build uses dual core not without a reason:
dosbox works on one core, mt32 emulation on the second core.
so get a dual core netbook first 😀

Reply 4 of 8, by TeaRex

User metadata
Rank Member
Rank
Member
robertmo wrote:

gulikoza's build uses dual core not without a reason:
dosbox works on one core, mt32 emulation on the second core.
so get a dual core netbook first 😀

Heh, maybe hyperthreading, which the Atom has, will help a bit... after all I'd assume that DOSBox doesn't use too much floating point math or other SSE heavy code if you use it to run programs that don't use the FPU. And I'd also assume that Munt is pretty heavy on FP. So hyperthreading should (fingers crossed) be able to distribute the stuff across the two virtual core.

Other than that, thanks to all of you for the help.

@gulikoza: I'll try out what you're saying as soon as I get the time (not before the weekend probably). It sounds easy enough.

tearex

Reply 5 of 8, by frobme

User metadata
Rank Member
Rank
Member

So hyperthreading should (fingers crossed) be able to distribute the stuff across the two virtual core.

Ehhh...hyperthreading basically gives you a low cost method of context switching between threads. It's certainly better than nothing, but it doesn't give you anything close to the ability of a true dual-core proc.

Munt is processor intensive because you can't "catch up" on frames with a sound output solution - when the input conditions change, you need to compute the new waveform data very quickly in real time or the user will have a perceptible aliasing or (if you use too much buffer) the sound will be out of sync with the display. Even tens of milliseconds start to be noticeable. Atoms are in-order execution processors with low cycle rates, so this kind of stuff is just plain hard for them.

Hope it works out though, I've been putting off playing a few games until I get my own build running with recent MT32 emulation as well, because I don't want to experience them in reduced form from back in the day =). Wish I had kept my MT32, sigh.

-Frob

Reply 6 of 8, by canadacow

User metadata
Rank Member
Rank
Member

We had a time last year where development on MUNT was improving rather rapidly. To improve our analysis of the few remaining parameters it was decided to switch all math from fixed point (intergers only) to floating point. This had a pretty signficant performance penalty--even on very modern CPU's.

I've been busy doing iPhone/iPad development recently so I haven't had any time/interest in going back and returning much of the math back to fixed point.

Reply 7 of 8, by robertmo

User metadata
Rank l33t++
Rank
l33t++
canadacow wrote:

This had a pretty signficant performance penalty--even on very modern CPU's.

Do you mean even modern CPU's don't have enough power for music emulation even if they devote their whole one core to the music emulation. Cause if whole one core have enough power it doesn't really matter as modern CPUs almost always have some not used cores.

By the way I noticed (while playing "Dune 2" soundtracks) that mt32 emulator actually plays proper instruments, but i think the only problem left is that some instruments are extremely silent, and some are extremely loud, and some are somewhere in between. And I think that is the reason why emulation sounds totally wrong with those soundtracks. (At the beginning I thought it plays wrong instruments, but it seams that it is only the volume that is the problem)