VOGONS


First post, by marooned_on_mars

User metadata
Rank Member
Rank
Member

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)

Attachments

  • Filename
    benchmark.zip
    File size
    11.81 KiB
    Downloads
    93 downloads
    File license
    Fair use/fair dealing exception

Reply 1 of 19, by bloodbat

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 2 of 19, by sergm

User metadata
Rank Oldbie
Rank
Oldbie
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...

Reply 3 of 19, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

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

Attachments

  • CPU load graph.png
    Filename
    CPU load graph.png
    File size
    20.89 KiB
    Views
    2054 views
    File license
    Fair use/fair dealing exception

Reply 4 of 19, by robertmo

User metadata
Rank l33t++
Rank
l33t++

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

Reply 5 of 19, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

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

Reply 8 of 19, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

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

Reply 9 of 19, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

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.

Attachments

  • 1.1.1.png
    Filename
    1.1.1.png
    File size
    1.72 KiB
    Views
    2017 views
    File comment
    mt32emu_qt v.1.1.1. Using defaults
    File license
    Fair use/fair dealing exception
  • new_la32_wg.png
    Filename
    new_la32_wg.png
    File size
    1.76 KiB
    Views
    2017 views
    File comment
    mt32emu_qt new la32 wg. Using defaults
    File license
    Fair use/fair dealing exception
  • ring.png
    Filename
    ring.png
    File size
    1.57 KiB
    Views
    2017 views
    File comment
    same mt32emu_qt new la32 wg but uses ring buffer
    File license
    Fair use/fair dealing exception
  • ring_win32_drv.png
    Filename
    ring_win32_drv.png
    File size
    1.67 KiB
    Views
    2017 views
    File comment
    media player + win32 driver using ring buffer.
    File license
    Fair use/fair dealing exception

Reply 11 of 19, by marooned_on_mars

User metadata
Rank Member
Rank
Member
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:
Y1nCwhv.png

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* 😁

Attachments

  • Filename
    dosbox.conf
    File size
    13.86 KiB
    Downloads
    90 downloads
    File license
    Fair use/fair dealing exception
Last edited by marooned_on_mars on 2013-03-02, 14:05. Edited 1 time in total.

Reply 12 of 19, by sergm

User metadata
Rank Oldbie
Rank
Oldbie
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 🤣

Reply 13 of 19, by marooned_on_mars

User metadata
Rank Member
Rank
Member
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.

Reply 14 of 19, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

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 😁

Reply 16 of 19, by marooned_on_mars

User metadata
Rank Member
Rank
Member
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:

4SkxLKn.png

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

DgR6eU3.png

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.

Attachments

  • Filename
    580.zip
    File size
    3.01 KiB
    Downloads
    88 downloads
    File license
    Fair use/fair dealing exception

Reply 18 of 19, by Mau1wurf1977

User metadata
Rank l33t++
Rank
l33t++

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

My website with reviews, demos, drivers, tutorials and more...
My YouTube channel

Reply 19 of 19, by marooned_on_mars

User metadata
Rank Member
Rank
Member

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!