MUNT 98 Testing

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

Re: MUNT 98 Testing

Postby sergm » 2017-9-20 @ 05:44

95DosBox wrote:I'm going to use my saved image from DOS 7.1 and overwrite the C: boot partition to restore it back. Then it should allow me to run Win ME but retain the DOS 7.1 front without patching.


I'm afraid this won't work. But you are free to try.
sergm
Oldbie
 
Posts: 734
Joined: 2011-2-23 @ 16:37

Re: MUNT 98 Testing

Postby sergm » 2017-9-20 @ 06:07

95DosBox wrote:When run on XP on a dual core at 1.6GHz I found that it barely scratches the CPU utilization of 8% average and 12% peak on DOSBOX but Munt doesn't seem to even hit 1%.


These figures are not very accurate. I was able to fool the performance tools in Windows XP by setting audio chunk size to 1 millisecond, so Windows XP showed effectively 0 CPU usage. In Vista+, performance measurements are way more accurate, and I never saw such bullshit numbers in newer Windows.

95DosBox wrote:SergM I think the MUNT98 files there is something that is not optimized correctly because it should actually run faster on 9X despite being a single core. I would think even a 1.0 to 1.5 GHz single core would be more than enough power to run DOSBOX with MUNT98 but in comparison with XP it should be 400MHz. I'm not sure why but I'm willing to help you troubleshoot what is causing this extreme sluggishness. Is there anything in the code you are compiling that could be causing the unexplained CPU load?


First, I should pay attention that "MUNT98" doesn't exist. There is no dedicated support for Windows 9x in the codebase yet (but soon there will be). One notable thing is I had to use old MinGW compiler that provides for considerably less optimised code in order to ensure compatibility of C/C++ runtime libraries with Windows 9x. So, I suspect, this build really performs worse. Anyway, you should test both builds in exact same environment to make proper comparison.

95DosBox wrote:I also tested Mame emulation and 800 MHz it runs smoothly on the single core in 98. So if both DOSBOX and Mame have no issues with any sluggishness I think it's isolated to MUNT98.


There is one more thing to note. Since DOSBox+mt32emu-qt setup involves two components, it may suffer from intermediate delays. Would be interesting to see how it works in monolithic DOSBox compiled with mt32emu patch.
sergm
Oldbie
 
Posts: 734
Joined: 2011-2-23 @ 16:37

Re: MUNT 98 Testing

Postby sergm » 2017-9-20 @ 06:11

95DosBox wrote:Can you add a checkbox option to preload a MIDI INPUT from MIDIINPUT.cfg to skip an extra few steps so it's as simple as the XP version?


This is not how it works in Windows XP+. There is another component, mt32emu_win32drv. This one creates a Windows MIDI port and routes data to the synth (either internal or external). Windows 9x multimedia architecture is quite different, so there will be another driver soon. This makes the problem irrelevant for the case though still actual for other usages. I'll get to it afterwards.
sergm
Oldbie
 
Posts: 734
Joined: 2011-2-23 @ 16:37

Re: MUNT 98 Testing

Postby sergm » 2017-9-20 @ 06:20

95DosBox wrote:Also can you add a check box option to start MUNT in "Test MIDI Driver" mode which displays the MT-32 status info LED panel rather than the regular blank canvas? I would like to see this check box option for Munt98 and XP.


There is really no need to run an empty synth that just consumes resources. The "Test MIDI Driver" option is only intended to measure accuracy of MIDI timing. When mt32emu-qt encounters a connection from some external consumer, it creates (and soon will do so on Windows 9x) a new synth automatically, there is no need to start one manually. In order to open a connection to MIDI-in port, use the menu option "New MIDI port..." in the same "Tools" menu.

mt32emu-qt can also work in another mode running only a single synth instance. This is so called "pinned synth". When you enable "Pin Synth" checkbox on a synth, it won't be closed when unused, and it will be attached to any new incoming connections. This behaviour is somewhat closer to a real setup when you have a hardware unit connected, though it'll waste CPU resources when there is no MIDI application is connected to the emulator.
sergm
Oldbie
 
Posts: 734
Joined: 2011-2-23 @ 16:37

Re: MUNT 98 Testing

Postby 95DosBox » 2017-9-22 @ 15:06

First, I should pay attention that "MUNT98" doesn't exist. There is no dedicated support for Windows 9x in the codebase yet (but soon there will be). One notable thing is I had to use old MinGW compiler that provides for considerably less optimised code in order to ensure compatibility of C/C++ runtime libraries with Windows 9x. So, I suspect, this build really performs worse. Anyway, you should test both builds in exact same environment to make proper comparison.


The 9X test was done on a more powerful Skylake CPU i7 reduced to use only 1 core.

The XP comparison test was done on a relatively cheap low end Ivy Bridge Celeron with 2 cores set to 1.6GHz.

Given the extra CPU power and extra cache the Skylake 98 test shows that more needs to be done to optimize it for 98. I would guess this is more related to the OS code optimization since you would expect the newer generation i7 to perform way better and the fact it's running on 9X would increase it's performance even further compared to the XP overhead. Because the DOSBOX stand alone test was done using the SB emulation (no MUNT) and performed amazingly well at 800 MHz.

I believe when the MUNT is optimized for 98 it will run so smooth at even 800 MHz with DOSBOX on a modern system you will see tons of people possibly using these low end KabyLake Dualcore Celerons to use as DOSBOX MUNT systems. The single core should be enough power to take care of the emulation on both. And don't worry I'll be there to test and confirm any improvements when the code is optimized by you. I wouldn't be suprised if both DOSBOX and MUNT running on 400 MHz though 800 MHz is the lowest I can set it at.

There is one more thing to note. Since DOSBox+mt32emu-qt setup involves two components, it may suffer from intermediate delays. Would be interesting to see how it works in monolithic DOSBox compiled with mt32emu patch.

True but even running MUNT by itself would be a good way to gauge its own performance bottlenecks. For example that internal test midi program would avoid needing to interface with MIDIYOKE or the DOSBOX to get the Midi Signal. I'll have to see if a MIDI file of the demo I'm testing exists to do a straight MIDI performance test (without DOSBOX and MIDIYOKE).

I'll try to do a Vista test to see how it's compares in CPU resource usage % in comparison to XP.
Okay in Task Manager I have a Vista 64-bit with a quad core i5 running and the System was set to 1.6GHz to do a comparison to the dual core low end celeron. At peak DOSBOX will use 5% x 4 cores = 20% overestimate peak.
Munt on the other hand "mt32emu-qt.exe *32" shows at most between 0-1% x 4 cores = 4% overestimate peak.

So on Vista 64-bit if you correlate this down to a single core we are probably seeing no more than 25% usage combined. This test was done on the Police Quest 3 Demo with Munt MT-32 emulation only enabled so no SB effects.
20% max usage for DOSBOX on one core.
4% max usage for MUNT on one core.
User avatar
95DosBox
Member
 
Posts: 309
Joined: 2017-5-23 @ 09:34

Re: MUNT 98 Testing

Postby 95DosBox » 2017-9-22 @ 15:29

95DosBox wrote:I'm going to use my saved image from DOS 7.1 and overwrite the C: boot partition to restore it back. Then it should allow me to run Win ME but retain the DOS 7.1 front without patching.


I'm afraid this won't work. But you are free to try.


It should work since Win ME is booting off of 98 MSDOS 7.1 but any reason or cause you think it wouldn't?

95DosBox wrote:Can you add a checkbox option to preload a MIDI INPUT from MIDIINPUT.cfg to skip an extra few steps so it's as simple as the XP version?


This is not how it works in Windows XP+. There is another component, mt32emu_win32drv. This one creates a Windows MIDI port and routes data to the synth (either internal or external). Windows 9x multimedia architecture is quite different, so there will be another driver soon. This makes the problem irrelevant for the case though still actual for other usages. I'll get to it afterwards.


Thanks SergM, :).
The MidiYoke does make things more interesting. You can combine say MT-32 and SC-55 using different instruments for each Midi channel to make an interesting mix.

Yes my MIDIInput.cfg idea was about making it a little easier for the current 98 version to autoload MIDIYOKE junction 1 on manual launch without manually adding it.

I also found two more small bugs. If I copy the Munt folder to the startup folder of 98 and have it autorun on boot or if manually selecting it as an icon in the Programs Files listing it will pop up two identical windows pop up errors.

"A device attached to the system is not functioning"

Strangely if running the program as a Quicklaunch or desktop icon it doesn't give this problem.
You do not have the required permissions to view the files attached to this post.
User avatar
95DosBox
Member
 
Posts: 309
Joined: 2017-5-23 @ 09:34

Re: MUNT 98 Testing

Postby 95DosBox » 2017-9-22 @ 15:40

sergm wrote:
95DosBox wrote:Also can you add a check box option to start MUNT in "Test MIDI Driver" mode which displays the MT-32 status info LED panel rather than the regular blank canvas? I would like to see this check box option for Munt98 and XP.


There is really no need to run an empty synth that just consumes resources. The "Test MIDI Driver" option is only intended to measure accuracy of MIDI timing. When mt32emu-qt encounters a connection from some external consumer, it creates (and soon will do so on Windows 9x) a new synth automatically, there is no need to start one manually. In order to open a connection to MIDI-in port, use the menu option "New MIDI port..." in the same "Tools" menu.

mt32emu-qt can also work in another mode running only a single synth instance. This is so called "pinned synth". When you enable "Pin Synth" checkbox on a synth, it won't be closed when unused, and it will be attached to any new incoming connections. This behaviour is somewhat closer to a real setup when you have a hardware unit connected, though it'll waste CPU resources when there is no MIDI application is connected to the emulator.


The resources it consumes is minimal and I think a lot of people would say a small price to pay to closely resemble the real McCoy virtualized. ;)

Yes I have used the Pinned Synth but it still does use up the entire window.
I like the Munt LED panel shown by default instead of blank which also takes up wasted screen space anyhow when the Munt Synth is not on. It mimics a real MT-32 in front of you like the shiny black box I have although a way to compress / minimize it as an option to just the LED light display/message panel would be a great feature.

Sometimes when running a game you can see special "messages" and the "instruments info" especially on Sierra titles. Now at the moment the only way to mimic this is to have the Munt console window and the DOSBOX window side by side taking you out of full screen mode. Later it would be nice if we could shrink that MT-32 LED display panel so it can become an overlay inside the DOSBOX window with a transparency setting in case the user wants to see the MT-32 display panel as semi transparent or solid within the DOSBOX window / in the game. This would be the best version of MT-32 emulator you can bring aside from the sound authenticity it already is nearing perfection.
User avatar
95DosBox
Member
 
Posts: 309
Joined: 2017-5-23 @ 09:34

Re: MUNT 98 Testing

Postby sergm » 2017-9-22 @ 16:26

95DosBox wrote: Later it would be nice if we could shrink that MT-32 LED display panel so it can become an overlay inside the DOSBOX window with a transparency setting in case the user wants to see the MT-32 display panel as semi transparent or solid within the DOSBOX window / in the game.


What do you think about looking at a REAL LCD? http://www.vogons.org/viewtopic.php?p=581353#p581353
sergm
Oldbie
 
Posts: 734
Joined: 2011-2-23 @ 16:37

Re: MUNT 98 Testing

Postby sergm » 2017-9-22 @ 16:28

95DosBox wrote:If I copy the Munt folder to the startup folder of 98 and have it autorun on boot or if manually selecting it as an icon in the Programs Files listing it will pop up two identical windows pop up errors.


Wait. Why do you copy the entire munt folder there? :confused:
sergm
Oldbie
 
Posts: 734
Joined: 2011-2-23 @ 16:37

Re: MUNT 98 Testing

Postby sergm » 2017-9-22 @ 16:29

The MidiYoke does make things more interesting. You can combine say MT-32 and SC-55 using different instruments for each Midi channel to make an interesting mix.

Not MIDIYoke but the windows midi mapper. I miss it... :(
sergm
Oldbie
 
Posts: 734
Joined: 2011-2-23 @ 16:37

Re: MUNT 98 Testing

Postby sergm » 2017-9-22 @ 16:31

95DosBox wrote:It should work since Win ME is booting off of 98 MSDOS 7.1 but any reason or cause you think it wouldn't?


Just one: IIRC this didn't work...
sergm
Oldbie
 
Posts: 734
Joined: 2011-2-23 @ 16:37

Re: MUNT 98 Testing

Postby sergm » 2017-9-22 @ 16:36

I would guess this is more related to the OS code optimization since you would expect the newer generation i7 to perform way better and the fact it's running on 9X would increase it's performance even further compared to the XP overhead.


No, I don't expect Win 9x to perform any better on modern devices. It's quite inefficient internally yet does not support all features of modern hardware. From my experience, Win 9x is really faster than newer system on very old hardware with limited resources, most notably RAM. When you grant more resources, Win XP becomes faster doing majority of tasks at some point, even booting up. I don't realize what you are talking about...
sergm
Oldbie
 
Posts: 734
Joined: 2011-2-23 @ 16:37

Re: MUNT 98 Testing

Postby 95DosBox » 2017-9-27 @ 21:51

sergm wrote:
95DosBox wrote: Later it would be nice if we could shrink that MT-32 LED display panel so it can become an overlay inside the DOSBOX window with a transparency setting in case the user wants to see the MT-32 display panel as semi transparent or solid within the DOSBOX window / in the game.


What do you think about looking at a REAL LCD? http://www.vogons.org/viewtopic.php?p=581353#p581353


Unzipped and tried running it but either it's not compatible with XP or it needs an installer to incorporate the proper files.

But what that is showing is having a separate window. But if you examine your own Munt program you could include a checkbox setting for miniaturized console display window. Look at where you have the Munt console program loaded and if you look on the right where it says Synth there is smaller status window that clearly has an outline around "Emulation Mode: XXX"
If you made an option for the miniturized console display windows rather than the larger version then all you would need is to add another option for customized skin which someone (3rd party to avoid any copyright issues) could make the skin based off of the MT-32 or other console for people to apply so it fits the ROM they've chosen to envelop around the LCD display status screen. So you might have to remove the Pin Synth, Properties, and MIDI Message button windows. The volume slider might be left alone. So if it was a Black MT-32 Skin then you probably wouldn't see it was there but you could still adjust the slider even though it was hidden within the blackness. Maybe the volume slider icon could be made a darker grey light enough to see on top of the black skin.

But this is just for the within Windows environment miniaturized display. The other idea I had was somehow making it possible for this miniaturized version as an overlay within the DOSBOX screen so it can be seen within the game in Full screen.
User avatar
95DosBox
Member
 
Posts: 309
Joined: 2017-5-23 @ 09:34

Re: MUNT 98 Testing

Postby 95DosBox » 2017-9-27 @ 21:53

sergm wrote:
95DosBox wrote:If I copy the Munt folder to the startup folder of 98 and have it autorun on boot or if manually selecting it as an icon in the Programs Files listing it will pop up two identical windows pop up errors.


Wait. Why do you copy the entire munt folder there? :confused:


Because you need to load MUNT manually in Windows 98. In XP this isn't necessary as it runs in the background.
I put it in the 98 Startup Folder so it saves an extra step. You still need to add the MIDI Yoke Junction 1 for the MIDI Input for Munt98 so that step still hasn't been resolved which is why adding a MIDIINPUT.CFG file would preload saved MIDI Inputs from a previous session. This isn't necessary in XP. Without this step no MIDI signals from the DOSBOX will be sent to MUNT98. When you close MUNT98 or reboot Windows 98 you have to repeat these steps again each time.
User avatar
95DosBox
Member
 
Posts: 309
Joined: 2017-5-23 @ 09:34

Re: MUNT 98 Testing

Postby 95DosBox » 2017-9-27 @ 21:58

sergm wrote:
The MidiYoke does make things more interesting. You can combine say MT-32 and SC-55 using different instruments for each Midi channel to make an interesting mix.

Not MIDIYoke but the windows midi mapper. I miss it... :(


Yes you need the Windows 98 Instrument Configuration to do the mixing of instruments between the MT-32, SC-55, and others. But without a proper Windows MIDI Mapper like in XP this MIDIYoke seems to be a necessity. Any chance you can do the MIDI input routing internally in MUNT98 code? I believe MIDIYoke had released some source code for 98 so maybe worth looking at to get some ideas.

But without MIDIYoke you cannot add the MIDI input on Windows 98 to MUNT.

I did more testing and used MIDIYoke NT and used your MUNT98 to test in XP. So you can do this test in XP and see the steps I mentioned need to be added to simplify the 98 MIDI input process without using a 98 VM on XP.
Last edited by 95DosBox on 2017-9-27 @ 22:43, edited 2 times in total.
User avatar
95DosBox
Member
 
Posts: 309
Joined: 2017-5-23 @ 09:34

Re: MUNT 98 Testing

Postby 95DosBox » 2017-9-27 @ 22:02

sergm wrote:
95DosBox wrote:It should work since Win ME is booting off of 98 MSDOS 7.1 but any reason or cause you think it wouldn't?


Just one: IIRC this didn't work...


I'll have to try this myself. So you can't recall any errors or what exactly did or didn't work?

Did it boot into the MS-DOS 7.1?

Did you have the Boot partition with 7.1 and ME on another partition?

Was the problem running ME after?

Did it load to the desktop screen at all?

If not what was the message you got or problem?
User avatar
95DosBox
Member
 
Posts: 309
Joined: 2017-5-23 @ 09:34

Re: MUNT 98 Testing

Postby 95DosBox » 2017-9-27 @ 22:14

sergm wrote:
I would guess this is more related to the OS code optimization since you would expect the newer generation i7 to perform way better and the fact it's running on 9X would increase it's performance even further compared to the XP overhead.


No, I don't expect Win 9x to perform any better on modern devices. It's quite inefficient internally yet does not support all features of modern hardware. From my experience, Win 9x is really faster than newer system on very old hardware with limited resources, most notably RAM. When you grant more resources, Win XP becomes faster doing majority of tasks at some point, even booting up. I don't realize what you are talking about...


I'll agree 98 isn't efficient compared to XP but for using it say with DOSBOX and MUNT I think it can handle it just fine. Multitasking or doing multiple tasks on 98 like on XP would be where I would draw the line if you're running say 5 or more programs at once. But for gaming it seems to work quite well. As for boot time 98 will boot in 1 second to the MS-DOS 7.1. For the 98 to desktop it's probably like 5-10 seconds. XP SP3 on the other hands will run in the 1-2min range even on a clean install on the same SkyLake system. I know this because I've been doing these tests for the past few months almost nonstop. Also just to be clear I'm running 98 natively not in a VM. Same with XP natively and not in a VM. I know some people may be using VMs to run 98 and XP in Windows 7 or 10 which is not what I am doing and it would be an inaccurate representation of how it would perform run natively. It would be hard to separate how much the primary OS you are running the VM is affecting the performance of the VM and also VMs might not be using the best graphics cards or one optimized to run in 98 natively so you will see poorer performance than run natively in some cases.

Having done some tests of 98 on a P3 and P4 with 512MB and comparing it to the SkyLake there is a substantial boost in performance on just one core. 98 is limited to using only 1 CPU Core even if you don't force it in the BIOS. Also doing a test of Mame and comparing it to XP while bumping up the CPU MHz speeds the 98 performance outclassed the XP performance on the same MHz speed. In some cases 3.0 Ghz and higher was a bit too responsive and fast and around 1.5-2.0 GHz it seemed to be an optimal CPU speed when using 98. The only thing XP would be faster at is if the code was written to support multiple cores or the OS was able to do it even though it wasn't optimized.

So any significant performance boost for MUNT you'll have to optimize it to use more than one core or just let XP do it which is less efficient. But like you said your code is pretty optimized already but how was DOSBOX able to optimize their SB emulation to run even on 800 MHz in XP and 98? Maybe some ideas could be shared to optimize MUNT in the same fashion.

Some ideas for MUNT. If you added options to disable and ignore specific MIDI channels that way it would reduce the CPU usage. For example on the MT-32 with 16 Channels all enabled and if you were to disable 15 of the 16 channels would you see a substantial improvement and reduction of CPU usage assuming the channel that was enabled didn't receive the brunt of the MIDI activity?

Could other options like further reduced accuracy in the sound authenticity as a sort of balance for lower powered CPUs? For example if MUNT was at 95% accuracy at this moment for the 2.2 Build. By reducing the quality of the the emulation it would be 23% accurate or the quality of the signal was poorer but 95% emulation accurate?
For example if a recorded wave file could be outputted at 32-bit 192 kHz but it consumed near 100% CPU usage.
However if you were able to reduce the quality to 8-bit at 44.1kHZ or 22.05kHz quality but it consumed 20% CPU usage. Would something like this be possible in MUNT so the user could improve the MUNT performance at the cost of slightly worse emulation quality?

I can confirm that DOSBOX doing the SB emulation can run very well on SkyLake 1 core at 800 MHz in XP and in 98. MUNT98 required 3.0 GHz to effectively run smooth enough on the 1 core. On another test with an i5 Sandy Bridge underclocked to 1.6 GHz and forced to use 1 core on XP it seemed just barely enough to run DOSBOX with MUNT as certain points the CPU usage spiked to the 90% region but dipped down to around the 30-40% range for the most part. It really depends on the game and how intensely it uses the MT-32. Police Quest 3 seems to have a higher payload than Dune 2 during the intro sequence.

Also any update on if you can give MUNT its own MIDI volume adjuster level in the Volume control.
For example when I pull up my XP Master Volume control window.
Master Volume, Wave, SW Synth (This usually is hooked to the MS Roland GS Wavetable SW Synth), Line Volume, CD Volume, PC Beep.

Master Volume will control everything.
Wave unfortunately is where where MUNT is joined to along with DOSBOX Sound Emulation.
I would like to see if you could create an individual volume slider for the MT-32 Synth or MUNT Synth to the right of the "Wave" slider if you can and have the "Roland GS SW Synth" to the right of the "MUNT Synth".

I hope this made sense.
You do not have the required permissions to view the files attached to this post.
User avatar
95DosBox
Member
 
Posts: 309
Joined: 2017-5-23 @ 09:34

Re: MUNT 98 Testing

Postby Falcosoft » 2017-9-28 @ 02:22

I hope this made sense.

No, it does not :)
On Win9x/2000/XP the 'Master Volume' actually shows the mixer topology of the real sound hardware represented by the driver of the sound card. So no application can magically insert its own mixer control to your sound card's mixer panel. On Vista/7/8/10 the mixer topology is virtualized so you get per application wave out mixer controls by the system. But it has the unfortunate side effect that applications that use the traditional win32 mixer API can only control Wave out volume. Midi out, analog CD out, special HW controls like Bass/treble etc. are not visible anymore.
Wave unfortunately is where where MUNT is joined to along with DOSBOX Sound Emulation.

That's because all of them actually use the Wave out of the sound card.
For example on the MT-32 with 16 Channels all enabled and if you were to disable 15 of the 16 channels would you see a substantial improvement and reduction of CPU usage assuming the channel that was enabled didn't receive the brunt of the MIDI activity?

On hand hand the real MT-32 and Munt do not use 16 midi channels at once but 9. The standard layout is: 2-9 are melodic channels and 10 is the drum/percussion channel. With the help of SysEx messages you can reconfigure the channel layout to use other 9 (or less) channels out of 16. (that's what the set channels 2..10 and set channels 1..8,10 buttons do in the qt application's Synth Properties panel).
Your suggestion:
disable 15 of the 16 channels
has no sense at all. You would lose all the messages (even Note On messages!) that would use the other channels. So most likely you would get the notes of only one instrument that uses the enabled channel (all other instruments including drums would be missing).
Moreover the CPU usage of e.g. 9 note on messages on 1 channel or 1 note on message on 9 different channels is roughly the same. So the CPU usage does not depend on the used channels but the used polyphony (actually rendered voices). The default in case of Munt is maximum 32 active partials. If you reduce it to 16 you will get much less CPU usage but you sacrifice accuracy/quality.
For example if a recorded wave file could be outputted at 32-bit 192 kHz but it consumed near 100% CPU usage.
However if you were able to reduce the quality to 8-bit at 44.1kHZ or 22.05kHz quality but it consumed 20% CPU usage.

Munt internally always uses 16 bit integer or 32 bit floating point rendering at 32 kHz (this sample rate is required for emulation accuracy). All other sample rates are the result of a conversion that uses CPU cycles. So for the best results in terms of performance use 16-bit 32 kHz.
User avatar
Falcosoft
Member
 
Posts: 392
Joined: 2016-5-21 @ 13:46
Location: Pécs, Hungary

Re: MUNT 98 Testing

Postby sergm » 2017-9-28 @ 06:32

Falcosoft wrote:On Win9x/2000/XP the 'Master Volume' actually shows the mixer topology of the real sound hardware represented by the driver of the sound card. So no application can magically insert its own mixer control to your sound card's mixer panel.


I think there is a possibility, though. For example, the old Yamaha DS-XG software synth had a WDM driver that was able to respond to the Synthesizer mixer control. I suppose this is because I also used a WDM driver for the sound card, so all this worked seamlessly. But I don't want to go into the kernel mode to do things which can happily be done in the userland (even within a stand-alone application on other OSes). So, yes, I think this is not possible atm. Maybe someone else appear to be willing to create WDM driver or I get bored at some point, who knows ;)

Your suggestion: "disable 15 of the 16 channels" has no sense at all. You would lose all the messages (even Note On messages!) that would use the other channels. So most likely you would get the notes of only one instrument that uses the enabled channel (all other instruments including drums would be missing).
Moreover the CPU usage of e.g. 9 note on messages on 1 channel or 1 note on message on 9 different channels is roughly the same. So the CPU usage does not depend on the used channels but the used polyphony (actually rendered voices). The default in case of Munt is maximum 32 active partials. If you reduce it to 16 you will get much less CPU usage but you sacrifice accuracy/quality.


Exactly. The LA32 renderer is the most CPU intensive code, and the load is in the direct proportion to the number of active partials. Yes, we can add the option to reduce/increase the maximum number of active partials, so slow PCs (which are now out of luck) could work. But again, this option is already available in the mt32emu patch for DOSBox. Let me remind (in 3rd time?) DOSBox with integrated mt32emu library has much less overhead regardless of the OS it is running on. Isn't it the goal of the whole topic to make the overhead lower? Again, adding all those nice features like translucent LCD on top of the DOSBox screen seems to be easier within that patch rather than trying to squeeze all the possible performance of the 16-bit internals of Windows 9x...

Munt internally always uses 16 bit integer or 32 bit floating point rendering at 32 kHz (this sample rate is required for emulation accuracy). All other sample rates are the result of a conversion that uses CPU cycles. So for the best results in terms of performance use 16-bit 32 kHz.


One correction. There is also an additional emulation of analogue parts, specifically, the LPF after DAC. The default "accurate" mode increases the sample rate up to 48000Hz. Having turned it off (the option to "Digital path emulation only" in the synth properties) makes things considerably faster. Actually, this is why that option is there. Also, if 32000Hz is not supported by the audio system or the system makes sample rate conversion too slowly, you can gain some speed by setting the sample rate of mt32emu-qt to the native sound card rate but ensure to use "Fastest" SRC quality (that is, shitty linear interpolation).
sergm
Oldbie
 
Posts: 734
Joined: 2011-2-23 @ 16:37

Re: MUNT 98 Testing

Postby Falcosoft » 2017-9-28 @ 08:45

Hi,
think there is a possibility, though. For example, the old Yamaha DS-XG software synth had a WDM driver that was able to respond to the Synthesizer mixer control. I suppose this is because I also used a WDM driver for the sound card, so all this worked seamlessly.

Just one little correction: I have not said you cannot use the already existing 'soft synth' mixer line control. Instead :
So no application can magically insert its own mixer control to your sound card's mixer panel.
This was a response to 95DosBox's idea:
I would like to see if you could create an individual volume slider for the MT-32 Synth or MUNT Synth to the right of the "Wave" slider

The default "accurate" mode increases the sample rate up to 48000Hz. Having turned it off (the option to "Digital path emulation only" in the synth properties) makes things considerably faster.

Yes, and OVERSAMPLED increases the sample rate further to 96000Hz. AFAIK the COARSE and DIGITAL_ONLY only modes both use 32000Hz, that's why I suggested this sample rate (in the Vsti sample rate automatically triggers the corresponding ANALOG_OUTPUT_MODE that's why I used the sample rate terms). But thanks for the clarification that there is also a difference between the two 32000 Hz modes regarding CPU usage.
Last edited by Falcosoft on 2017-9-28 @ 09:00, edited 1 time in total.
User avatar
Falcosoft
Member
 
Posts: 392
Joined: 2016-5-21 @ 13:46
Location: Pécs, Hungary

PreviousNext

Return to MT-32 Development

Who is online

Users browsing this forum: No registered users and 1 guest