MUNT is quite demanding so I think that's your problem.

You can buy a MT-32 and use it with a USB - MIDI adapter.

Hi, I already have a real MT-32, but I´m looking for emulation

I dont think is only about MT-32 emulation being demanding...

Emulation of MT-32 inside DOSbox build is faster than using the driver...

Daum builds must use a very optimized MT-32 emulator or the munt driver is not optimized at all...

Yea MUNT focuses on accuracy and sounding right.

Mau1wurf1977 wrote:

Yea MUNT focuses on accuracy and sounding right.

Well, MT-32 emulation inside Daum Dosbox Build sound great! I cant hear much difference to my real MT-32, and compared to latest munt in my C2D machine, I cant hear any difference

Someone knows a way to install the Daum MT-32 munt version like a driver? I don't wanna use DOSbox for games that runs good in ntvm

Or maybe a unofficial optimized mt-32 build?

try dosbox with external munt too

I suppose the problem here is somewhat similar to discussed here Munt sluggishness in recent versions
We became to conclusion the problem is in different algorithms used to convert the sample rate of the Munt output. Munt now requires the sample rate of 32000 Hz to perform the emulation in most accurate manner. But we haven't included any sample rate conversion yet (and I think we shouldn't, actually, as e.g. libresample can be used externally and is quite independent of the emulation itself).

As I understand the problem (honestly didn't consulted with the DOSBox's sources), the DOSBox mixer perform fast linear interpolation resampling that saves a lot of CPU load for slow machine. But Windows/sound card driver can use more sophisticated filtering and that appears too slow.

Thanks sergm, I understand your reply

If all the problem came from the sample rate conversion, there is a way to build a munt that just output in a normal sample rate than windows sound card drivers don't need to convert?

Because is really very disappointing, and ridiculous, that a game emulated inside DOSbox, run much MUCH faster, than using in ntvdm + munt like a driver, specially when this same game, using ntvdm+sound blaster (vdmsound) only uses 10% CPU time....

For example, 4DSport Boxing:

4DBoxing + ntvdm + vdmsound (soudn blaster) = 10% CPU MAX (2,3% normal) <-- GREAT
4DBoxing + DOSBOX (Sound Blaster) = 35% CPU MAX <-- GREAT
4DBoxing + DOSBOX (MT-32) = 65% CPU MAX <-- GREAT

4DBoxing + ntvdm + Munt = 100% CPU <--- SLOW

Thanks!!

Yes, I'd like to make the problem clear as it seems to be not uncommon. Right, I'd start with a test driver build which produces output (inaccurate, be assured) at another sample rate, say 44100Hz (I think this sample rate is flawlessly supported by your sound card). Also, AFAIK, 44100Hz is the default sample rate of the DOSBox's mixer.

If the CPU load will be drastically lower with this build, I'll add simple and straightforward linear resampler to the driver.

Thanks sergm, and sorry my English is not good, is very difficult to explain problems

I have a real MT-32 connected to a 486 machine, and believe or not, i can´t hear almost to any difference from Dosbox and munt

I don't know if is 32khz, 44khz, or whatever, simply, I have both, the emulator and the real thing, and for me, sound exactly the same

For sure a "inaccurate" but faster build, will be very useful to many people with low end hardware

Thanks a lot for your reply, and effort to tried to understand my posts!!

Uploaded (hopefully, I didn't mess it up):
http://sourceforge.net/projects/muntreloaded/ … 00.zip/download

theelf wrote:

For sure a "inaccurate" but faster build, will be very useful to many people with low end hardware

It won't be too inaccurate. If the resampler really causes this problem, I add a faster resampler right to the driver.
Inaccuracies of using fast linear interpolation in resampler shouldn't be dramatic (though, it depends on the ear 😜). In theory, linear interpolation adds high-frequency noise which appears audible due to aliasing. So, good resampler uses a low-pass filter to remove unwanted frequencies. But the filter usually is a quite slow FIR (finite impulse response) for its good filtering abilities. So, until recently, most audio systems used low-quality linear interpolation by default (and even now most of them provides this option to save CPU load). But the actual problem you have no choice with Windows audio (or at least there is no documented UI to do so).

sergm wrote:

Uploaded (hopefully, I didn't mess it up):
http://sourceforge.net/projects/muntreloaded/ … 00.zip/download

Wah, sounds like a piece of shit but at least it produces some sound.

sergm wrote:

... the DOSBox mixer perform fast linear interpolation resampling that saves a lot of CPU load for slow machine. ...

^ Confirmed, according to the current SVN MixerChannel::AddSamples() does perform optimised fixed point linear interpolation to convert the sample rate of the mixer channel. I really hope the test version of the Munt driver will be faster for you, theelf.

sergm , sorry for the long delay to reply, I had too much work this days

I tested the driver you upload, but is the same problem, too slow

When I say "slow", is that for example, 10 times slower than real speed or worst

Today I tested your "SSE2 only" build, that I found in your website, mt32emu-qt_2012-06-17.zip , in my Laptop, that have a Pentium M 1ghz, and is amazing fast

I know a Pentium M 1ghz... is faster than a Athlon XP 1ghz... but "10" times faster?

It's ok but it doesn't seem related to the sample rate as I see. 😒
To finally close the sample conversion topic, I'd like you to perform one more test (actually, this should be done first but the greatest idea comes last 😀 ). Please, try DOSBox (either Ykhwong's or mine MT-32+ build which you can find next to the horrible ..44100 driver) with the native MT-32 sample rate set on mixer and compare the speed, i.e. set in your dosbox.conf
...
[mixer]
rate=32000
...

If DOSBox after this change performs as usual, I'll forget about resampling (at least for some time). Perhaps, it is related to Microsoft compiler "loves" old AMD. Maybe I should try to compile the driver with SSE enforced / other code optimisation changes. But this should be done carefully using batch SMF2WAV conversion watching the conversion time elapsed.

sergm, thanxs for reply

Sorry to ask a stupid question, I want to do all test you ask, and one of them is testing your DOSBox MT-32 build, but I always get "MT32_CONTROL.ROM Not found"

I copy MT32_CONTROL.ROM in the dosbox folder, in system32, in... well... in all places... but same error

About Ykhwong build, I tested with rate=32000, the speed is great, no changes in speed

I wanna try your build if I solve the rom problem... (sorry, i feel idiot to ask something like this problem...)

It should say "MT32: Control ROM file not found" if there is no "MT32_CONTROL.ROM" file in the _current_ directory, i.e. game directory if you start DOSBox to autorun a game.
*EDIT*
Though, looks like a bug... Try renaming ROMs to CM32L_CONTROL.ROM and CM32L_PCM.ROM
Hmmmm, interesting. The ROM file opening pattern is exactly the same in Ykhwong's sources 😎 but his version works 😕

Hi sergm!

Thanks for the fast reply, sorry, I write bad, yes, is "MT32: Control ROM file not found" 😊

But, your solution is right, I rename both files to CM32L_CONTROL.ROM and CM32L_PCM.ROM, and your build works great

Well, I can say your Dosbox build is very similar in CPU usage to Ykhwong´s build, congratulation!! 😀

Here is 3 test,I use game "Lotus 3" (I love the music!!)

First Ykhwong build, using Sound Blaster, can you see the CPU usage is from 8% in the music select area

Second Ykhwong build, using MT-32 emulation, CPU usage raise to 17% in the music select area

And finally, your DOSBox version, using MT-32, CPU usage is near same Ykhwong build, no big difference

If inside DOSbox, munt emulation works great, but using munt a standalone driver is slow like hell, I think that must be some problem in the munt "windows driver"

I don´t know if helps or not, but I installed the last Munt driver (1.2) and tested a midi file, using te Media Player, and MT-32 for midi out, and CPU usage was near 60%-70% !

I don´t know if helps or not, but I installed the last Munt driver (1.2) and tested a midi file, using te Media Player, and MT-32 for midi out, and CPU usage was near 60%-70% !

That's really weird if it isn't related to sample rate conversion but to WinMME handling. It seems to be useful to test mt32emu-qt playing this MIDI file (using internal MIDI player I mean) and see the CPU load.