VOGONS


First post, by nogmog

User metadata
Rank Newbie
Rank
Newbie

Please forgive me if this has been made clear in readme's or other guides, but i'm trying to understand the true preferred CPU requirements in order to have munt running "as it should". The only information i've been able to glean is reference to an 800Mhz CPU minimum spec. But obviously I won't just have munt running, because I want this for dosbox. So would a 1Ghz CPU cut it? I know it depends on the game being played, but i'm really only talking about mt-32 games. Also, does more L1 (cpu cache) make any difference to performance?

Reply 1 of 16, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

I'd avoid announcing any particular figures. This question is very specific. Speaking of speed requirements, we need to clarify an acceptance criterion. It may be OK if sound drops are rare and short, or it may be required that sound shall never drop. It matters which hardware components the system has, which drivers are installed, whether there is hardware acceleration in the sound card available, which other programs are running, which software settings are set, etc. Also, MHz measure is different for CPUs of different brands. So, the fair answer would be "you should try it".

In my case, I put 800 MHz as the rough approximation only. My Celeron III was running quite stable playing various MIDI files but the CPU load was high enough. Now, the synth engine is considerably faster, though.

Reply 2 of 16, by nogmog

User metadata
Rank Newbie
Rank
Newbie

Well i've got a p3 650 and playing "canyon.mid" keeps me in the 95-100% region, which is fair, based on the recommended min CPU. I was curious if there was a "sweet spot" so to speak whereby you could you could pretty much guarantee smooth playback, allowing for O/S overhead and dosbox. Don't really have access to a range of cpu's to trial and error on.

Reply 3 of 16, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++

Hmm... what about collecting some data points?

As noted previously in other threads, I've tested on an Atom N270 single core with HT on clocked at 1.6ghz. With the vector units enabled, Munt runs smoothly along with DOSBox emulating at the approximate speed of an early 386. This is on an x86 install of Linux. I've also tested on a Pi 2 featuring quad ARM Cortex A7 cores at 900mhz. So long as the power adapter is sufficient to prevent voltage dipping (and therefore downclocking) and the proper compiler optimizations are set, this SoC runs Munt without sound drops while DOSBox is operating on one of the spare cores. Max CPU load is about 80%.

All hail the Great Capacitor Brand Finder

Reply 4 of 16, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

nogmog

If your CPU load is below 100%, you can usually achieve dropless playback by increasing audio buffer. I think the generic approach here is measuring the time spent on conversion MIDI->WAV. If your system is able to perform the conversion in less time than the duration of the tune (with some spare), it should also be able to play it in realtime. The CPU time used by DOSBox and other applications can be estimated in direct proportion to their CPU load percentage.

Anyhow, PIII 650 doesn't seem to be a good choice for DOSBoxing with MT-32 emulation enabled on board. I think even DOSBox itself on 3000 cycles/sec will take about 10-20% of CPU. So, taking into account the figure you've achieved with munt, there seems to be no room for both.

And note, that canyon.mid isn't really a good sample for testing MT-32 emulation. Better be it not a GM tune. 😉

Reply 5 of 16, by nogmog

User metadata
Rank Newbie
Rank
Newbie
sergm wrote:
nogmog […]
Show full quote

nogmog

If your CPU load is below 100%, you can usually achieve dropless playback by increasing audio buffer. I think the generic approach here is measuring the time spent on conversion MIDI->WAV. If your system is able to perform the conversion in less time than the duration of the tune (with some spare), it should also be able to play it in realtime. The CPU time used by DOSBox and other applications can be estimated in direct proportion to their CPU load percentage.

Anyhow, PIII 650 doesn't seem to be a good choice for DOSBoxing with MT-32 emulation enabled on board. I think even DOSBox itself on 3000 cycles/sec will take about 10-20% of CPU. So, taking into account the figure you've achieved with munt, there seems to be no room for both.

And note, that canyon.mid isn't really a good sample for testing MT-32 emulation. Better be it not a GM tune. 😉

Ok thanks for the tip and info. I'll have a good play around and test with a faster CPU.

Reply 7 of 16, by nogmog

User metadata
Rank Newbie
Rank
Newbie

So I had a bit of an epiphany.

I was watching one of the awesome Scummvm videos from PhilsComputerLab which suggested I can run all (or pretty much all) of my mt-32 games through scummvm and using the built in mt-32 emulator. So I fired up PQ3 and CPU utilisation was about 65-75% and I did not notice any drops or laggy audio/gameplay! I'm pretty happy about this but I guess the emulation vs interpreter explains the drop in cpu utilisation, although I don't know if there's a technical difference between using the built in mt 32 in scummvm or using munt?

Oh and I tried Loom. Wow. Never played it before and the soundtrack is incredible...!

Reply 8 of 16, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++
nogmog wrote:

Oh and I tried Loom. Wow. Never played it before and the soundtrack is incredible...!

Glad you like it. I think the soundtrack is a bit more complex than most as it seems to peg the CPU higher than most other test tracks I have.

All hail the Great Capacitor Brand Finder

Reply 9 of 16, by sherman

User metadata
Rank Newbie
Rank
Newbie
nogmog wrote:

So I had a bit of an epiphany.

I was watching one of the awesome Scummvm videos from PhilsComputerLab which suggested I can run all (or pretty much all) of my mt-32 games through scummvm and using the built in mt-32 emulator. So I fired up PQ3 and CPU utilisation was about 65-75% and I did not notice any drops or laggy audio/gameplay! I'm pretty happy about this but I guess the emulation vs interpreter explains the drop in cpu utilisation, although I don't know if there's a technical difference between using the built in mt 32 in scummvm or using munt?

Oh and I tried Loom. Wow. Never played it before and the soundtrack is incredible...!

Yeah, the Loom soundtrack is beautiful.

Of course, it should be, as it (the main theme at least) is basically an arrangement of themes from Tchaikovsky's Swan Lake ballet (which I happen to really enjoy)...

Reply 10 of 16, by matze79

User metadata
Rank l33t
Rank
l33t

whats ram requirement for munt ?

https://dosreloaded.de - The German Retro DOS PC Community
https://www.retroianer.de - under constructing since ever

Co2 - for a endless Summer

Reply 11 of 16, by sergm

User metadata
Rank Oldbie
Rank
Oldbie
matze79 wrote on 2020-07-08, 19:30:

whats ram requirement for munt ?

Short answer: modest for many use cases.

Given a more detailed definition of "munt", and considering the platform to run it on, it should be possible to clarify the memory requirements further. Besides, some programs are able to load a MIDI file into RAM entirely, or create multiple synth engines, so these may require additional memory to perform the desired task actually.

Reply 12 of 16, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++

It varies a bit depending on the architecture. On an Ivy Bridge CPU with speed optimizations, the VSS for mt32d is about 500k. So it's small.

gdjacobs 14961  4.5  0.1 442480  8604 pts/0    Sl+  21:27   0:19 ./mt32d

All hail the Great Capacitor Brand Finder

Reply 14 of 16, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++
sergm wrote on 2020-07-09, 08:02:

Hmm, that looks a bit tricky. Only MT32_PCM.ROM itself is about 512K, and CM32L_PCM.ROM is twice as big. I guess RSS is ~8.6Mb here 😀

Bah! Resident set of 8M. Units are 1 kbyte, not 1 byte. With all the libraries linked in with portaudio, we're talking just under 500mb.

Sometimes I be stupid.

All hail the Great Capacitor Brand Finder

Reply 15 of 16, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

Feel free to ignore VSS. Those are really virtual 😀
I guess RSS and its parts (anon/file) are more important. Still, it includes space occupied by shared libs, so this may be used by more than 1 process...

Reply 16 of 16, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++

You can't really ignore VSS, but RSS is certainly more important as it's active code and data including those parts of shared libraries that are being used.

All hail the Great Capacitor Brand Finder