Munt sluggishness in recent versions

Developer's Forum for discussion of bugs, code, and other developmental aspects of the Munt Project.

Munt sluggishness in recent versions

Postby marooned_on_mars » 2013-3-01 @ 19:22

Continued from here.

sergm wrote:This sounds really weird. I'd recommend you to benchmark pure emulation core performance using smf2wav. No system (mis-)configuration interference. Just the raw numbers. Select a tune, convert it using smf2wav or mt32emu_qt conversion menu item, and let's compare the time elapsed. The reference MIDI you can either attach or put an URL for me.
And I think we'd better move to another thread as this one seems not right for the matter.


I attached the midi file to this post. It took ~15 seconds to convert. It's a track from LSL6 from Shamra's room You'll probably hear a few stretched notes as I explained in the thread.
At the beginning of the song where there's only percussion it's fine, but once that new wave synth instrument starts playing it slows down and it skips a lot.

robertmo wrote:what happens if you try the same ykhwong build, but just with disabled internal mt32 emulation and using external one?


I haven't thought about that, thanks for the suggestion. It doesn't perform better that the normal DosBox or my SVN build (on mididevice=win32 instead of mt32)
You do not have the required permissions to view the files attached to this post.
User avatar
marooned_on_mars
Member
 
Posts: 361
Joined: 2006-1-23 @ 18:47
Location: MoonBase2

Re: Munt sluggishness in recent versions

Postby bloodbat » 2013-3-02 @ 06:23

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.
User avatar
bloodbat
Oldbie
 
Posts: 783
Joined: 2009-12-06 @ 07:11

Re: Munt sluggishness in recent versions

Postby sergm » 2013-3-02 @ 06:50

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...
sergm
Oldbie
 
Posts: 734
Joined: 2011-2-23 @ 16:37

Re: Munt sluggishness in recent versions

Postby sergm » 2013-3-02 @ 07:03

And finally, here's the CPU load graph. Ykhwong's build 2013-02-05, CPU @800MHz. :lol:
You do not have the required permissions to view the files attached to this post.
sergm
Oldbie
 
Posts: 734
Joined: 2011-2-23 @ 16:37


Re: Munt sluggishness in recent versions

Postby sergm » 2013-3-02 @ 08:50

@ 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
Oldbie
 
Posts: 734
Joined: 2011-2-23 @ 16:37

Re: Munt sluggishness in recent versions

Postby robertmo » 2013-3-02 @ 09:17

sergm you should edit your results post with that piii info :)

marooned_on_mars enclose your dosbox.conf
User avatar
robertmo
l33t
 
Posts: 4160
Joined: 2003-6-18 @ 10:35

Re: Munt sluggishness in recent versions

Postby sergm » 2013-3-02 @ 09:26

Yup, benchmarking now...
sergm
Oldbie
 
Posts: 734
Joined: 2011-2-23 @ 16:37

Re: Munt sluggishness in recent versions

Postby sergm » 2013-3-02 @ 09:35

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...
sergm
Oldbie
 
Posts: 734
Joined: 2011-2-23 @ 16:37

Re: Munt sluggishness in recent versions

Postby sergm » 2013-3-02 @ 11:11

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.
You do not have the required permissions to view the files attached to this post.
sergm
Oldbie
 
Posts: 734
Joined: 2011-2-23 @ 16:37

Re: Munt sluggishness in recent versions

Postby sergm » 2013-3-02 @ 11:53

BTW, the binaries of the latest build I used uploaded @ https://sourceforge.net/projects/muntre ... e96df6edd/ for reference.
sergm
Oldbie
 
Posts: 734
Joined: 2011-2-23 @ 16:37

Re: Munt sluggishness in recent versions

Postby marooned_on_mars » 2013-3-02 @ 13:54

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. :disapproving:
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:
Image

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



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* :happyhappy:
You do not have the required permissions to view the files attached to this post.
Last edited by marooned_on_mars on 2013-3-02 @ 14:05, edited 1 time in total.
User avatar
marooned_on_mars
Member
 
Posts: 361
Joined: 2006-1-23 @ 18:47
Location: MoonBase2

Re: Munt sluggishness in recent versions

Postby sergm » 2013-3-02 @ 14:02

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 :lol:
sergm
Oldbie
 
Posts: 734
Joined: 2011-2-23 @ 16:37

Re: Munt sluggishness in recent versions

Postby marooned_on_mars » 2013-3-02 @ 14:31

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 :lol:


I checked and the CPU is not underclocked. It's at the default speed it was designed for. No power-saving mode under BIOS.
User avatar
marooned_on_mars
Member
 
Posts: 361
Joined: 2006-1-23 @ 18:47
Location: MoonBase2

Re: Munt sluggishness in recent versions

Postby sergm » 2013-3-02 @ 14:37

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 :D
sergm
Oldbie
 
Posts: 734
Joined: 2011-2-23 @ 16:37

Re: Munt sluggishness in recent versions

Postby robertmo » 2013-3-02 @ 14:45

try
output=surface
aspect=false
scaler=none
core=dynamic
rate=22050
mpu401=intelligent
User avatar
robertmo
l33t
 
Posts: 4160
Joined: 2003-6-18 @ 10:35

Re: Munt sluggishness in recent versions

Postby marooned_on_mars » 2013-3-02 @ 15:09

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 :D


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:

Image

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

Image

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


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.
You do not have the required permissions to view the files attached to this post.
User avatar
marooned_on_mars
Member
 
Posts: 361
Joined: 2006-1-23 @ 18:47
Location: MoonBase2

Re: Munt sluggishness in recent versions

Postby sergm » 2013-4-28 @ 09:44

btw, the DOSBox+MT32emu updated to v.1.2.0 of the emulation core.
http://sourceforge.net/projects/muntrel ... t/download
sergm
Oldbie
 
Posts: 734
Joined: 2011-2-23 @ 16:37

Re: Munt sluggishness in recent versions

Postby Mau1wurf1977 » 2013-4-28 @ 11:14

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).
User avatar
Mau1wurf1977
l33t++
 
Posts: 7652
Joined: 2010-8-27 @ 04:15
Location: Western Australia

Re: Munt sluggishness in recent versions

Postby marooned_on_mars » 2013-4-28 @ 12:45

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!
User avatar
marooned_on_mars
Member
 
Posts: 361
Joined: 2006-1-23 @ 18:47
Location: MoonBase2


Return to MT-32 Development

Who is online

Users browsing this forum: No registered users and 1 guest