VOGONS


MUNT 98 Testing

Topic actions

Reply 40 of 54, by sergm

User metadata
Rank Oldbie
Rank
Oldbie
Falcosoft wrote:

Just one little correction: I have not said you cannot use the already existing 'soft synth' mixer line control.

Yep, you're right 😀

Falcosoft wrote:

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. But thanks for the clarification that there is also a difference between the two 32000 Hz modes regarding CPU usage.

True.

Reply 41 of 54, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

Though, having WDM driver for Windows 9x and XP does look appealing. Possible advantages:
1. Making use of the mixer Synth volume control if integrating mt32emu driver as a minidriver for the WDM portclass driver.
2. 32-bit mode that enables the internal synth engine to be included.
3. Creation of MIDI ports without registry hacks.
4. Making use of available (bad) emulation of MPU-401 in a DOS session.

Though, none of them are superior to existing solutions. For instance, the controls of output gain in mt32emu-qt can boost volume in contrast to that mixer control. #3 seems not a problem on Windows XP at all. #4 has no value if DOSBox is used and when comparing to VDMSound solution.

Anyway, I wonder if LoopMIDI works (can be made to work) in WDM mode on the Windows 9x platform...

Reply 42 of 54, by 95DosBox

User metadata
Rank Member
Rank
Member
Falcosoft wrote:

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.

I did see some application that allowed rerouting of audio virtually but I didn't have time to investigate and test. But I think the best solution is to find a way for MUNT to feed the MIDI output to the Sound Card's MIDI Volume control if you can't create an independent one. But having studied a few sound card drivers it seems to be a few registry entries that causes these mixer controls to show up and it probably could be done but it would have be done inside the driver on a per sound card basis which wouldn't be globally done for everyone. Routing the MIDI signal from MUNT using the MIDI Mapper shouldn't there be some way to allow you to control the MIDI Volume of MUNT through the Master Mixer Volume Control or is that somehow only reserved for the sound card's own SW Synth?

Another way might be hacking the actual Master Mixer Volume Control for the SW Synth volume control and make the adjuster lever actually send the same exact command signals as the MUNT console sound level adjuster. I'm not sure if that's easier if it's not possible to add a virtual MIDI Synth volume adjuster into the Master Mixer Volume Control as you stated.

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).
So Midi Channels 1-10 are used in MUNT but 11-16 are not emulated since they don't do anything?

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

Yes that is the point. When I was experimenting with MIDIYoke and the way 98 can customize the channels it allowed me to hear each channel individually. In some cases by not having that particular MIDI channel activated the track could sound better or cleaner with less going on. But it also opened up the door to customize the other channels to be assigned to another MIDI device. For example the MS Roland GS Wavetable Synth which had virtually no CPU load. I guess the idea was if the MUNT Console allowed a ON/OFF button switch for each of the 16 Channels to reduce LOAD. It would ignore the OFF channels so it wouldn't do any unnecessary emulation.

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.

I'm not sure I follow you here due to less internal MIDI knowledge. So for each channel if it had a note activated does it activate a rendered voice? Or are you saying it requires two notes activated before it taxes the CPU to blend them? Can you explain what you mean by partials in this case? And you mentioned halving 32 to 16 would be a way to reduce CPU load but how far can it go 8, 4, 2, and 1? And is performance improved by a factor of 2 as you halve it?

If so it might be worth testing this out even though sacrifice in the quality of it would be reduced but this does open the doors for even an old P3 / P4 to get better MIDI output than the Sound Blaster MIDI output or in some older games that didn't have digitized sound effects even a poor sounding MT-32 is better than the PC internal speaker and probably better than the original 8-bit Adlib or 8-bit SB Mono.

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.

Could an 8 bit integer option be possible to reduce CPU load at the sacrifice of emulation accuracy for slower systems? The lowest could be 4 bit integer from what I can find so adding these two lower bit integer options might have a drastic CPU load drop on slower systems.

Reply 43 of 54, by 95DosBox

User metadata
Rank Member
Rank
Member
sergm wrote:

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 😉

I hope you get bored at some point. 😉 I can't remember if your MUNT is source code open or not but it'll probably take me more time to learn how to to do it than you but if say really don't think you can do it or due to time or lack of interest I might be willing to put my resources into it. But again I'm open to trying to figure out how to do it on my own with your source code and make it happen.

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

Is there a way to include options for 8 bit and 4 bit integer and keep the 32 kHZ sampling rate if that reduces load?

On 64-Bit CPUs running on XP 32-bit is there a way for your program to tap the CPU directly and do 64-bit rendering if it at all can speed up the emulation?

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

Okay for myself I prefer not to use an integrated DOSBOX with MUNT. I actually like DOSBOX v0.72 since I dislike the splash screen and I think all custom DOSBOX version integrated with MUNT are probably using 0.74 or later. I actually had a whole list of DOS commands that don't work properly in DOSBOX which I wanted corrected but I doubt the developer is interested in fixing them.

Also as far as overhead "not running" DOSBOX but just MUNT XP would actually perform better in some cases since DOSBOX does add overhead. For example in XP as I stated previously I could run some of DOS programs in XP "Command Prompt" and your MUNT XP correctly intercepts the MIDI commands directly. So this is actually "less overhead".

However if you're asking me to try to combine DOSBOX 0.72 source code with your MUNT 2.2 for testing if you have the software necessary for me to compile and integrate 0.72 and your MUNT 2.2 into one and add my DOS commands fix to improve the DOSBOX interface I would do that myself. First off I need to know what programs I will need to compile DOSBOX 0.72 source code into the workable version you download and run. Second where do I get your MUNT 2.2 source code and how do I compile that independently as you have it on your site so it's runnable with an installer?

Third I still want to combine some of my DOS authentic commands into DOSBOX that were done incorrectly. Then the last stage is how do I combine both DOSBOX and your MUNT 2.2 and integrate them as you say. Maybe I can create my own independent version and some of these ideas can be transplanted into your version later once I figure it all out.

Reply 44 of 54, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++
95DosBox wrote:

I can't remember if your MUNT is source code open or not

LGPL IIRC
https://github.com/munt/munt

All hail the Great Capacitor Brand Finder

Reply 45 of 54, by sergm

User metadata
Rank Oldbie
Rank
Oldbie
95DosBox wrote:

Maybe I can create my own independent version and some of these ideas can be transplanted into your version later once I figure it all out.

Yes, I think it'd be advantageous to master building DOSBox on your own. Both DOSBox and munt are free software, so this way is really encouraged.

95DosBox wrote:

For example in XP as I stated previously I could run some of DOS programs in XP "Command Prompt" and your MUNT XP correctly intercepts the MIDI commands directly. So this is actually "less overhead".

Once again, munt does not intercept anything within a DOS session on Windows XP. Windows XP has native VDD support that allows the MIDI stream to pass from a DOS game to a Windows MIDI port. But not 100% correctly, e.g. if the intelligent mode of MPU-401 is used by the game.

Reply 46 of 54, by Falcosoft

User metadata
Rank Oldbie
Rank
Oldbie

So Midi Channels 1-10 are used in MUNT but 11-16 are not emulated since they don't do anything?

More precisely 2-10 are used in both real MT-32 and Munt by default. As I have written you can configure Munt to use other 9 channels (so e.g. 1-5, and 13-16 is also possible). But all the game music and midi songs written for MT-32 use channels 2-10. So the point is Munt can emulate all the possible channel configuration layouts but only 9 channels at once just like the real hardware( and by default uses channels 2-10 just like the real hardware).

Yes that is the point. When I was experimenting with MIDIYoke and the way 98 can customize the channels it allowed me to hear each channel individually. In some cases by not having that particular MIDI channel activated the track could sound better or cleaner with less going on. But it also opened up the door to customize the other channels to be assigned to another MIDI device. For example the MS Roland GS Wavetable Synth which had virtually no CPU load.

Yes, the midi mapper of Win9x makes it possible to assign different devices to different channels. Arguably the midi mapper of Windows became more and more dumb with each Windows generation, Win3.1 midi mapper being the most advanced and Win9x midi mapper the 2nd best.
But there is a problem. In practice if you want to play MT-32 compatible games/songs, all the other possible synths are GM/GS and not MT-32 compatible. So if you used Munt on e.g. channel 2-6 and MS Soft Synth on channels 7-10 you would get wrong instruments on channel 7-10 (the drum channel is the less problematic). So while this way the CPU usage can be lowered you won't get a proper sound. Different latencies can also be a problem. The sound of the instruments that are assigned to different devices will not be in sync. Most likely the instruments played by Munt would start earlier because of Munt's better latency (compared to MS synth).

I'm not sure I follow you here due to less internal MIDI knowledge. So for each channel if it had a note activated does it activate a rendered voice? Or are you saying it requires two notes activated before it taxes the CPU to blend them? Can you explain what you mean by partials in this case? And you mentioned halving 32 to 16 would be a way to reduce CPU load but how far can it go 8, 4, 2, and 1? And is performance improved by a factor of 2 as you halve it?

In this context consider partials as the voices that has to be emulated/rendered to hear audio. The point is CPU usage depends on the actual rendered partials and it does not matter what channels the partials use. So if you have a piano song with a single instrument and you send all the note messages to only channel 2 you get nearly the same CPU usage as you send the same notes distributed to all channels (2-9). Only the amount of the active partials matters.
I have made a little experiment and made a video about it. The CPU was set to 1.8 GHz. As can be seen in the first part the CPU usage is almost proportional to the active partials. In the second part a real MT-32 midi is used (Monkey Island intro) that has a maximum partial usage somewhere between 16-32. As can be seen in this case the maximum CPU usage with maximum 32 active partials is almost 1.5x the maximum CPU usage of 16 maximum partials. I used Munt Vsti for the test because it has maximum active partials settings and a somewhat better interface for this test. But notice it uses the exact same engine as the Munt drivers.

https://youtu.be/h1iZF8kJVn8

Website, Facebook, Youtube
Falcosoft Soundfont Midi Player + Munt VSTi + BassMidi VSTi
VST Midi Driver Midi Mapper

Reply 47 of 54, by 95DosBox

User metadata
Rank Member
Rank
Member
sergm wrote:

Yes, I think it'd be advantageous to master building DOSBox on your own. Both DOSBox and munt are free software, so this way is really encouraged.

Thanks Sergm, however I'm more interested in focusing on Munt since it's not complete. 😊 But as far as official DOSBOX MUNT integrated which is the latest version you recommend using? I'll do another comparison of performance between independently running both versus integrated.

What compiler programs do you use yourself to compile the Munt source code into the final windows executables?
I want to use the same exact software so don't worry about finding me freeware alternatives as I'm only interested interested in using exactly what you are using.

Which direct link can I get the exact source code file for Munt 2.2 that you're compiling?

Sergm, just to let you know I'm not a programmer like yourself but I just need your help pointing me correctly but I intend to try and help make it better. I've only hacked and modified programs so don't worry about over explaining in detail. I just want to replicate exactly what you do from taking the source code and compiling to the final uploaded version you distribute. Then once I've refined those steps I will start tweaking it and logging any changes I did so later I could extrapolate that in case you want to add it into the official MUNT.

I probably have over 1000 DOS titles and maybe more when I have more time I'm going to to do some comparison with your MUNT vs my real MT-32 to discern any bugs. I'm not sure how passionate you are still about making MUNT near 100% or you're really down to your last efforts and ready to retire it soon. I ordered a USB MIDI adapter to test on a newer system that lacks PCI slots so I could later do a side by side comparison on each machine and sync it.

Reply 48 of 54, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

If building DOSBox on your own, I think it's always best to take advantage of new features available in the most recent SVN version.
As for building munt programs, I have to run several virtual machines with different OSes each with own set of C++ compilers and build tools. I tend to prefer the "most usual" compiler for each platform with basic set of compiler options for better compatibility, so I don't think it'll be interesting for you to do the same. For release builds, you can find the source files zipped in the download section of the project page.
Good luck! 😀

Reply 49 of 54, by 95DosBox

User metadata
Rank Member
Rank
Member
sergm wrote:

If building DOSBox on your own, I think it's always best to take advantage of new features available in the most recent SVN version.
As for building munt programs, I have to run several virtual machines with different OSes each with own set of C++ compilers and build tools. I tend to prefer the "most usual" compiler for each platform with basic set of compiler options for better compatibility, so I don't think it'll be interesting for you to do the same. For release builds, you can find the source files zipped in the download section of the project page.
Good luck! 😀

I guess I wasn't specific enough. I assume you use the VMs for Linux and MAC OS so I'm not planning on working on those versions ATM so you can exclude those for now. 😀

I don't need to worry about any VMs since I will be running the OS straight so you can assume I'm using the actual OS to be compiled in.

SergM, can you be more specific of the actual programs you use to code Munt for XP and for the 9X version?

And what programs do you use to compile the source code for XP and for the 9X version to the final windows executable for release for each?

Reply 50 of 54, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

Ah, These two... 😀
Well, I did mention exact versions of the GNU compiler and the Qt library I used to build the Win9x crap. The 32-bit binary for the fully-functional Windows OSes is built using Microsoft C++ compiler version 15.00.30729.01

Reply 51 of 54, by 95DosBox

User metadata
Rank Member
Rank
Member

Hello sergm,

While Munt98 works fine under 98SE,

I've had time to do more legacy testing. I managed to get the older version running on a Z370 Coffee Lake system I have.

It turns out even on the single core it can handle the necessary CPU strains for the Munt emulation.

This opens the door for using a modern machine for Munt processing with the smallest footprint.

I found some other issues in my Munt98 testing. I starting testing all flavors of 9X and ME.

Unfortunately Windows 95 OEM, 95A, 95B, and I think even on 98 First Edition (might have to recheck this one going off memory). These could not run Munt98 without some popup dependency error.

Can you recompile Munt98 v2.3 so that it supported down to the lowest dependency for Windows 95 OEM?
If it works for 95 OEM it should work for every version all the way to Windows ME without issue.

Let me know when you do and I'll do some more testing.

Reply 52 of 54, by matti157

User metadata
Rank Member
Rank
Member

Hello,
I am trying to activate MT-32 emulation on my Thinkpad T42 with Windows 98. The processor is a 1.5ghz Pentium should do it.

I quickly tried last night with The Games: Winter Challenge (1991) which supports MT-32 but it didn't work.

1) Download this mt32emu_qt-1.7.1-win9x.zip
2) Download this mt32emu_win32drv-git_ac4f1f0dee-win9x.zip
3) I add a new multimedia device by selecting this driver mt32emu_win32drv-git_ac4f1f0dee-win9x.zip (OEMSETUP.INF)
4) I go to Control panel \ Multimedia \ MIDI tab and under "single instrument" I select MT-32 instead of the Microsoft one
5) I start the exe file in mt32emu_qt-1.7.1-win9x.zip which opens a console and another program. I keep them open without closing them
6) I start the game and select MT-32 in the settings

But no audio is played

Last edited by Stiletto on 2020-12-30, 06:23. Edited 1 time in total.

Reply 53 of 54, by matti157

User metadata
Rank Member
Rank
Member

Update:
I also tried with Space Quest 3 but it tells me it can't find the audio device

However, if I open a .mid file via media player MUNT is activated, I hear the audio and see the information on the virtual display.

If I open a DOS game on the console instead I see this:

Win32MidiDriver: Invalid midiSession ID supplied: "0x29"
Win32MidiDriver: Invalid midiSession ID supplied: "0x29"
Win32MidiDriver: Invalid midiSession ID supplied: "0x29"
Win32MidiDriver: Invalid midiSession ID supplied: "0x29"
Win32MidiDriver: Invalid midiSession ID supplied: "0x29"
Win32MidiDriver: Invalid midiSession ID supplied: "0x29"
Win32MidiDriver: Invalid midiSession ID supplied: "0x29"
Win32MidiDriver: Invalid midiSession ID supplied: "0x29"
Win32MidiDriver: Invalid midiSession ID supplied: "0x29"
WinMMAudioDriver: Processing thread stopped

Works with media player:
mt-32.png

Reply 54 of 54, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

Hello matti157,

Unfortunately, there is no simple way to make MT-32 emulation work with DOS games in a raw console session of Win9x. As you can find earlier in this forum, merely installing mt32emu_qt and mt32emu_win32drv is not enough to get MT-32 music output from a DOS game, one also needs to route MIDI messages from the DOS application to the Windows MIDI port the driver creates. If you tried to use DOSBox, it'd work out of the box (since DOSBox is in fact a Windows application and able to connect to MIDI ports directly). However, this way may be unacceptable for you due to additional performance overhead, so you can also try VDMSound for Win9x which is supposed to add proper emulation of MPU-401 device and facilitate MIDI routing as appropriate. Sadly, the project was dropped a long time ago, remaining in the alpha stage...