So..what you're saying is your processor is POS? (Intel Celeron D) ahmmm...yeah...I agree; and that it probably has a load of crap loaded in RAM it shouldn't? Maybe taking cycles? Yeah, I agree too.

marooned_on_mars wrote:

I attached the midi file to this post. It took ~15 seconds to convert.

This is really amazing.
Here's the results on my system.

@2.8GHz, "new LA32 engine", mt32emu-qt.exe convert:
AudioFileWriter: Elapsed seconds: 4.56992, CPU load ~50% (as only one core is used)

@2.8GHz, release 1.1.1, mt32emu-qt.exe convert:
AudioFileWriter: Elapsed seconds: 5.61731, CPU load ~50%

@800MHz, "new LA32 engine", mt32emu-qt.exe convert:
AudioFileWriter: Elapsed seconds: 15.9963, CPU load ~50%

@800MHz, release 1.1.1, mt32emu-qt.exe convert:
AudioFileWriter: Elapsed seconds: 19.6149, CPU load ~50%
===========================================
What could this mean? Hmm, are you sure about your CPU frequency? I think there's a malware being able to play with hardware resources...

And finally, here's the CPU load graph. Ykhwong's build 2013-02-05, CPU @800MHz. 🤣

you cannot compare GHz of different cpus...
http://www.cpubenchmark.net/cpu.php?cpu=Intel … leron+D+3.06GHz

http://www.cpubenchmark.net/cpu_lookup.php?cp … +3.06GHz&id=693
http://www.cpubenchmark.net/cpu_lookup.php?cp … n+X2+240&id=196

@ robertmo

I known what are you talking about. Obviously, recent CPUs performs better at the same clock frequency. But when I refer to 800 MHz minimum I didn't meant underclocked multicore CPU. I still have my good old Intel Pentium III 800 MHz. When I tested munt on that system it behaved marginally, just as marooned_on_mars described. Now, when a faster engine is available, I assume it performs a bit better.

Looking at the tables you linked, no doubt, my old system sucks vs. marooned_on_mars (benchmark index 238 vs. 265).

sergm you should edit your results post with that piii info 😀

marooned_on_mars enclose your dosbox.conf

Yup, benchmarking now...

As expected:
new LA32 version: AudioFileWriter: Elapsed seconds: 27.1088
version 1.1.1: AudioFileWriter: Elapsed seconds: 32.1891

i.e. there is some time for CPU to perform other tasks... though, it's average and in dynamic, peak overloads could appear. Will a bit later...

Here's the CPU graphs. Running DOSBox with 3000 cycles seems overkill for my system. DOSBox with ~650 cycles feels the same as using MIDI players.

As you can see, using the ring buffer can save the day as it make the load closer to the average.

So, I think I could update the 800 MHz requirement in the munt's README if I was able to test it on a slower system... But on the system with about twice faster CPU, it should perform well no doubt. Your CPU most probably in power saving mode. This explains fast batch conversion and poor real-time performance.

BTW, the binaries of the latest build I used uploaded @ https://sourceforge.net/projects/muntreloaded … d182ce96df6edd/ for reference.

bloodbat wrote:

So..what you're saying is your processor is POS? (Intel Celeron D) ahmmm...yeah...I agree; and that it probably has a load of crap loaded in RAM it shouldn't? Maybe taking cycles? Yeah, I agree too.

I would've known that by now and wouldn't have bothered to ask or pester people around here if it was a RAM of too many cycles issue. 😒
The RAM usage while testing was ~40%-50%, and what's the point in lowering the cycles when I was able to double them without problems? Also there are some games that don't play decently under this.
For benchmarking lowering cycles is good but for gameplay it's bad.

sergm wrote:

What could this mean? Hmm, are you sure about your CPU frequency? I think there's a malware being able to play with hardware resources...

I am quite sure that I got the CPU freq right:

Also I don't think it's possible to have malware on my system as I only use Chromium for HTTP accesses.
It really is amazing how your PC can beform better even underclocked. Besides the varied performances between CPUs (like robertmo pointed) could it be a chipset issue as well? Mine's quite a bit outdated (not even a PCIe slot, come on!). But since marooned on mars like I am, I can't really complain...

robertmo wrote:

you cannot compare GHz of different cpus... http://www.cpubenchmark.net/cpu.php?cpu=Intel … leron+D+3.06GHz […]
Show full quote

you cannot compare GHz of different cpus...
http://www.cpubenchmark.net/cpu.php?cpu=Intel … leron+D+3.06GHz

http://www.cpubenchmark.net/cpu_lookup.php?cp … +3.06GHz&id=693
http://www.cpubenchmark.net/cpu_lookup.php?cp … n+X2+240&id=196

I like it how the CPU I use is placed riiiiiight in the middle of the graph *sigh*

robertmo wrote:

sergm you should edit your results post with that piii info 😀

marooned_on_mars enclose your dosbox.conf

I attached it to the message =)

sergm wrote:

So, I think I could update the 800 MHz requirement in the munt's README if I was able to test it on a slower system... But on the system with about twice faster CPU, it should perform well no doubt. Your CPU most probably in power saving mode. This explains fast batch conversion and poor real-time performance.

I doubt there's a power saving mode here as I'm not on a laptop. Or I might be unaware of such a mode, but wouldn't then CPU-z detect a slower CPU speed?

But regardless, thanks for all the benchmarking... and destroying my conspirational theory that I might've found a bug in Munt *grumble grumble* 😁

marooned_on_mars wrote:

...wouldn't then CPU-z detect a slower CPU speed?

Unfortunately, this is well possible. For example, when underclocking my big desktop CPU-z shows horrible crap and windows system properties still shows 2800 MHz 🤣

sergm wrote:

Unfortunately, this is well possible. For example, when underclocking my big desktop CPU-z shows horrible crap and windows system properties still shows 2800 MHz 🤣

I checked and the CPU is not underclocked. It's at the default speed it was designed for. No power-saving mode under BIOS.

The last question:
How does it sound / loads the CPU without DOSBox? When playing a MIDI file just using mt32emu_qt MIDI player or windows media player? I need to know how much I must ask for my old PC 😁

try
output=surface
aspect=false
scaler=none
core=dynamic
rate=22050
mpu401=intelligent

sergm wrote:

The last question:
How does it sound / loads the CPU without DOSBox? When playing a MIDI file just using mt32emu_qt MIDI player or windows media player? I need to know how much I must ask for my old PC 😁

I'll attach the midi I used for playback, I chose a standard GM midi since the other one was horrid without sysex.

Playing it gave me an average load between 40-80%, it skipped during those spikes you see in the graph:

Also, interestingly I have observed (by accident) that when I fast forward through the song the CPU usage is much lower with no spikes:

This could either mean it's expected to behave like this or it's not really a CPU problem but a crap soundcard that has bugs (I have a C-Media 8738 PCI card)

robertmo wrote:

try output=surface aspect=false scaler=none core=dynamic rate=22050 mpu401=intelligent […]
Show full quote

try
output=surface
aspect=false
scaler=none
core=dynamic
rate=22050
mpu401=intelligent

Thanks, I'll try those settings in a bit and report the results. Also I never knew the difference between intelligent and uart. Is it performance or accuracy based?

EDIT: Nothing much changed except the buggy surface display. The dynamic core seems to not work and the sample rate change didn't do much as the munt driver is set to output at a certain rate.

btw, the DOSBox+MT32emu updated to v.1.2.0 of the emulation core.
http://sourceforge.net/projects/muntreloaded/ … latest/download

I tried DSOBox and MUNT (latest versions) on a notebook with AMD E-300 CPU (VERY slow CPU) and it worked just fine. Maybe 40% CPU usage all up. I played a Sierra Game (Codename: Iceman).

Thanks for updating the build, sergm! =D

EDIT: Another thanks to sergm for this fix:
In the case anyone is using this build of DosBox and you experience skipping or instruments playing at a irregular tempo/losing sync, try changing the mt32.thread option in dosbox.conf to on.

sergm explains:

it is set to "off" by default which means the DOSBox will wait until the mt32emu core processes each millisecond of the output data.
Setting this option to "on" forces the emulation to process the output by much larger chunks (iirc, 15 ms or so) which means less overhead and in a separate thread (unfortunately, a single core CPU won't benefit of that) which means DOSBox might perform more smoothly.
So, this roughly simulates the performance of the DOSBox + mt32emu win32 driver.

Thanks again sergm!