sergm wrote:

...
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 😕

Hopefully fixed. I was too sleepy writing FileStream stuff 😜
Uploaded fixed DOSBox build: http://sourceforge.net/projects/muntreloaded/ … 20.zip/download

Hi sergm, great, thanks for updating DOSbox

About what do you ask, I use mt32emu-qt from mt32emu-qt_2012-06-17.zip and from munt 1.2 on to play a midi file

I did what I think are very useful?¿ 😵 test

I build 2 machines (today is saturday i have time jaja) + my laptop + Athlon 1ghz + my desktop C2D 1.6ghz

I made the test with this machines, playing standar midi file town.mid from media windows directory

1) Pentium 3 1.2ghz - 35-60% CPU
2) Athlon 1ghz - 60-95% CPU
3) C2D 1.6ghz - 5-9% CPU
4) Athlon XP 2200 - 50-85% CPU !!!?¿¿¿??
5) Pentium M 1ghz laptop - 15-25% CPU

Wow, what a big difference from the Pentium 3 to the Athlon XP 2200....

I made another test in my C2D 1.6ghz

Dosbox + munt (windows driver) + lotus 3 = 15-30% CPU
DOSbox sergm + internal MT-32 emulator + lotus 3 = 5-10% CPU

This is a HUGE difference!! is 3 times the CPU just for use the windows driver.....

Dramatic...

But you missed one thing I guess. When you play a SMF using mt32emu_qt INTERNAL MIDI player, it doesn't make any use of the Windows driver (surprise hehe). So, this GREAT difference can only be caused by using WinMME (in both the driver and mt32emu_qt) for audio output vs. DSound used by DOSBox by default.

Another interesting thing to test with your systems is offline conversion of a reference SMF and see the elapsed times. This test will show the pure system processing power (in the sense of emulation) without any Windows MIDI/audio system interference.

Also, I think town.mid isn't a great sample for MT-32 emulation as it is a GM file. I'd use a MT-32-only file from, e.g. Quest Studios or whatever...

sergm, hi

Very interesting information you say about the qt player

I still have all motherboard spread around the house, but I will need to put all in boxes later, then now is time to all possible test

How do a offline conversion of a smf? sorry, I don't know about this, sorry

I use town.mid, because is in all windows, easy if someone join and wanna do test. But I use a MT-32 file from Quest Studios like you say

I downloaded the music from Larry 1 (my favorite !) in MT-32

The results are very similar to the ones from town.mid, but with lower CPU requeriments

For example the Athlon XP 2200, while playing larry music, have a 20% to 80% CPU

The C2D from 4 to 6%

Oops, forgot to mention...
In the main window of mt32emu_qt you can locate "Tools" menu in the main menu. It contains two options I'd like you to try: "Play MIDI file..." and "Convert MIDI to Wave...". To easily measure elapsed conversion time you should show debugging console by clicking "Show console" item in the popup menu of the Munt's system tray icon.

Oh, those "intuitive" user interfaces... 😉

Hi sergm!

If I don´t understand bad, I made what do you say

I downloaded Larry 1 midi from Quest Studios, and convert to wav in mt32emu_qt , then after finish, i checked the console

I get this results

CD2 1.6ghz = 258 seg
Athlon XP 2200 = 435 seg
Pentium M = 402 seg
Pentium 3 1.2ghz = 582 seg
Athlon XP 1ghz = 738 seg

Cool, let's compare this with the CPU load you posted:

1. C2D 1.6ghz - 5-9% CPU
2. Pentium M 1ghz laptop - 15-25% CPU
3. Pentium 3 1.2ghz - 35-60% CPU
4. Athlon XP 2200 - 50-85% CPU
5. Athlon 1ghz - 60-95% CPU

1. CD2 1.6ghz = 258 seg
2. Pentium M = 402 seg
3. Athlon XP 2200 = 435 seg
4. Pentium 3 1.2ghz = 582 seg
5. Athlon XP 1ghz = 738 seg

Somewhat surprising behaviour displays Athlon XP 2200 but all the other numbers look consistent. Please, see how the CPU load during playing the SMF via mt32emu_qt corresponds to the numbers you got with DOSBox...

If we divide the elapsed time by the tune duration, we can see the perfect average CPU load to try to get as close as possible...
1. CD2 1.6ghz = 258 seg (9%)
2. Pentium M = 402 seg (14%)
3. Athlon XP 2200 = 435 seg (15%)
4. Pentium 3 1.2ghz = 582 seg (20%)
5. Athlon XP 1ghz = 738 seg (26%)

Hi sergm, plase can you explain to me hoy to play smf files? I dont know this kind of files, or have any in my HD

Sorry

Ah, SMF is just an acronym for "Standard MIDI file". About any file .mid you have is a SMF in fact. 😀

I think I better make a build of mt32emu_qt with 44100 Hz output sample rate. I'm afraid we might mess something up with the driver. Just to be sure this slowdown isn't caused by the resampler...

oki, jaja, sorry about smf

Ok, I will keep all computers in the table, to test in any momment

http://sourceforge.net/projects/muntreloaded/ … 00.zip/download uploaded. Please try...

Hi sergm, I download the new mt32emu-qt, and I tested with a standard midi file

The CPU usage is much higher than normal one from munt 1.2

(screenshot from Athlon XP 1ghz)

C2D = 15-30% CPU
Athlon XP 2200 = 70-95+ %
Pentium 3 = 60-85%
Pentium M = 40-70%
Athlon 1ghz = 95 - 100+ % (slowdown)

I hope this test is useful

Thanks

Hmm...
The resampler seems innocent.
What about changing the audio output device to "Portaudio (1) your-audio-device-here"? - this should use DSound (check this in the debugging console). Be sure to restart the emulator engine to really change the audio output device.

Hi sergm!

Ok, I change to - Portaudio Dsound - my device - and now CPU use is a little lower

For example:

C2D = 10-18%
Athlon XP 1ghz = 70-95+%
Pentium M = 25-50%

EDIT: I build the Athlon and P3 again!

EDIT: I build the Athlon and P3 again!

That's great but I think we have too many configurations to test and it looks to me not all of them suffer from the problem in the topic. I'd like to focus on one configuration with which we see "Super fast DOSBox+MT-32 but very slowww mt32emu Win32 driver" problem.

Actually, I'm still uncertain how this is possible... All three systems (unfortunately, all three are quite decent vs. yours, dual core AMD Athlon II X2 240, AMD Turion 64 X2, and Intel P6200) I tested display the opposite trend, i.e. good CPU load with the driver (20-40% depending on the tune playing), (when underclocking to 800-900 MHz, the CPU load is about unmeasurable when they run at full speed) a bit higher with my DOSBox build and yet a bit higher with Ykhwong's (all tested with default settings).

Also note that the CPU load for dual core systems is measured as an average over two cores, and the emulation is single threaded.

When I try DOSBox at full speed, the CPU load meter shows 0 whereas with the driver it shows a few percent of load. I assume this is due to imperfect Windows performance counters. The difference is DOSBox by default performs audio rendering by 1 millisecond chunks, and the driver uses 10 millisecond chunks by default. So, the process scheduler might consider a time slice not fully used by the emulation as "free". 😀

Anyway, I also tested Munt with my old Intel PIII 800 MHz system but the results are not so nice as yours. It seems totally incapable of running DOSBox with MT-32 emulation. Even DOSBox itself takes 20% of CPU (without any sound output) for 3000 emulation cycles. So, the sound was awful until I reduce the emulation cycles down to 1000. But it was acceptable (well, no underflows and crackles at least) when I tried mt32emu_qt and its internal MIDI player and it was ok with Media player + driver as well.

So, I'm personally very interested in solution of this problem but alas I have no possibility to diagnose it properly. 🙁

Playing some time with my old PIII 800 MHz PC, I've found one thing which might help with this issue. When you open "Audio Properties" dialog in mt32emu_qt app, you can adjust several options of the rendering engine. They apply both to the mt32emu_qt itself and the Windows driver (it reads parameters set to the WinMMAudio devices via this dialog). So, when I turn on the "Use ring buffer renderer" checkbox, the CPU load becomes more smooth, as I've already noted in the marooned_on_mars thread. But besides this, WinMME behaves much better when I set audio buffer and chunk sizes to "nice" numbers (powers of two) like 16, 32 or 1024, etc. For example, the following configuration shows good CPU load close to the average (not horrible sines as it is with the default settings):
- Chunk length = 32
- Audio latency = 256
- MIDI latency = 40 (it should generally be at least a little greater than the chunk length to overlap possible jitter, but the greater the better)
- "Use ring buffer renderer" = off

Btw, DOSBox also uses "nice" values from the fixed set for the blocksize variable in the mixer section (1024 is the default). Though, I'm not completely understand the cause as mt32emu engine usually requires resampling and in theory any audio buffer size can be used with no difference in speed... But this seems not the case with Windows. 😀 Maybe it depends on the sound card in use. In my case it is Yamaha DS-XG. So, it may take advantage of the aligned properly sized buffer and reduce CPU load by hardware acceleration. So can do sound card drivers in your case, theelf.

sergm

Thanks for the reply, Im not in home now, I can use internet, but I dont have my computers near me

Tonight I will test the audio buffer, chunk sizes, because, I never take a look at this, and maybe is a solution!!

I understand very well, is so difficult to test, if we don't have similar hardware 😵 but, i wanna say thank you for all the time you lost answering my problem

Later I will post again, thanks