Reckless wrote:

Excellent work on this release. Just been pumping an old game soundtrack (Hand of Fate) through it and it sounds fantastic! Just WOW!

Oh, thanks 😎

Honestly, there are a few things which still offend an ear. Like that in Zeliard capture I posted above. And similar thing breaks perfectness when listening to Dune Palace or Water Themes. And so on.

collector wrote:

There seems to be a move on Windows towards XML in the user's AppData folder. What Reg key are you using?

The trend is clear. But Qt still uses the registry. The access keys are formed using "organization" and "application" names, as usual, i.e. "muntemu.org" and "Munt mt32emu-qt". So, the keys are:
HKEY_CURRENT_USER\Software\muntemu.org\Munt mt32emu-qt
and
HKEY_LOCAL_MACHINE\SOFTWARE\muntemu.org\Munt mt32emu-qt

The latter is a system-wide key. It can be used to setup some defaults for all the users (manually so far). Maybe, I'll add some system-wide setup options further.

sergm wrote:

robertmo wrote:

Cannot Install MT32Emu MIDI driver. There is no MIDI ports available.

Windows allows only 10 MIDI drivers, BAD luck 🙁

But see if you can delete entries like midiX=wdmaud.drv in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32. Usually this crap appears after a USB-MIDI device get reconnected to a different USB port. And I've found no kernel MIDI driver that really needs that midiX=wdmaud.drv entry.

It looks i have a serious mess in there caused mostly by testing lots of usb sound card prototypes. They took all following ports:
midi-midi9
aux-aux9
wave-wave9
mixer-mixer9
I noticed that deveices installed later don't use alias in:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{long_number}\00XX\Drivers\
I was wondering whether there is some move polite form of removing that mess. I could for example uninstall Virtual Sound Canvas to free one midi and one wave port.
But I was wondering if i could uninstall those usb sound drivers too. In Win9x there was a possibility to boot into safe-mode and uninstall old unused devices/drivers in device manager. In winxp/win7 i don't see those old devices even when i choose "show hidden devices". So is there any way to do it for winxp/win7?

This is what the system restore is intended for. Alternatively, I suppose it's a job for a registry cleaner thingy 😀
If I understand all this stuff correctly, you can safely remove any midi/aux/wave/mixer entries that are aliases for kernel drivers, i.e. wdmaud.drv. And the lack of available midi* entries is the only issue preventing mt32emu driver to install and work correctly.
We had a thought of making it a kernel driver too, but I prefer not to go deep into the kernel mode if not strongly necessary (just hate rebooting, kernel dumps, etc. 🤣).

robertmo wrote:

I was wondering whether there is some move polite form of removing that mess. I could for example uninstall Virtual Sound Canvas to free one midi and one wave port.
But I was wondering if i could uninstall those usb sound drivers too. In Win9x there was a possibility to boot into safe-mode and uninstall old unused devices/drivers in device manager. In winxp/win7 i don't see those old devices even when i choose "show hidden devices". So is there any way to do it for winxp/win7?

Look here:
http://www.sevenforums.com/hardware-devices/7 … tml#post1690515

Maybe, just maybe, SysInternal's AutoRuns could help you.

bloodbat wrote:

Look here:
http://www.sevenforums.com/hardware-devices/7 … tml#post1690515

That is exactly what I was looking for. I was able to clean all the mess easily now. One important thing to add - you have to "show hidden devices"

Has there been an increase of CPU power required in the latest munt versions? I tried some of ykhwong's builds and they were very slow here when having MT-32 emulation enabled and it's very choppy, depending on what the game requires in regards to processing. I thought to myself that maybe as ykhwong builds usually have a lot of neat stuff compiled in it I thought maybe some component in it is making things slow. So I decided to compile my own DosBox SVN with the latest Munt but I found out it has the same problem. Munt's readme says the minimum requirement for it to properly emulate a MT-32 is 800MHz while I have a 2.26GHz single-core CPU. I have DosBox running at 4000cycles (which here is close to a low-end 386), takes 100% CPU and the music is very choppy.

Not sure what is "the latest munt versions" you mean here. I'm pretty confident that the latest version (1.1.1) I released on 2013-02-16 uses the same emulation engine and consumes no more (and no less) CPU power.

On the other hand, the new LA32 wave generator model I recently committed to master (the latest commit cd182ce96df6edd4ae2e8f3feefe938d08bd96df eventually sounds about nice) really works a bit slower. But according to my tests, it performs worse when compiled in debug mode only (MS VC 2008 used to build). In release mode it performs a bit faster. Actually, as expected. As about only additions are used in the critical path. So, it works both faster and more accurate. I love it. 😀

Though, I want to make it more accurate in terms of pitch before the release.

sergm wrote:

Not sure what is "the latest munt versions" you mean here. I'm pretty confident that the latest version (1.1.1) I released on 2013-02-16 uses the same emulation engine and consumes no more (and no less) CPU power.

By the "latest" I mean 1.1.1 compared to pre-1.0 and earlier 1.0 versions.
In that case I must've been doing something wrong that I can't put my finger to. Maybe while compiling it picked up a munt variant that was meant for multi-core processing?
I'm sorry for the illiteracy, I'm still new to compiling things ^^;

sergm wrote:

On the other hand, the new LA32 wave generator model I recently committed to master (the latest commit cd182ce96df6edd4ae2e8f3feefe938d08bd96df eventually sounds about nice) really works a bit slower. But according to my tests, it performs worse when compiled in debug mode only (MS VC 2008 used to build). In release mode it performs a bit faster. Actually, as expected. As about only additions are used in the critical path. So, it works both faster and more accurate. I love it. 😀

I'm curious as to what difference that makes in terms of sound (not performance, since you cleared that one out, hehe.

At least FFT spectrum now looks much closer to the real digital captures provided by KingGuppy.

FYI: posted dosbox_cd182ce96df6edd.zip to
http://sourceforge.net/projects/muntreloaded/files/

sergm wrote:

FYI: posted dosbox_cd182ce96df6edd.zip to
http://sourceforge.net/projects/muntreloaded/files/

The file doesn't show up for some strange reason.

EDIT: Nevermind, it shows up now.
Thanks for that, it seems to be working flawlessly here and it doesnt strain the CPU or cause choppiness. Also curious how the executable in my build takes 11MB and yours is a meagre 2MB. I used the SVN but it couldn't have been that much of a difference...

marooned_on_mars wrote:

The file doesn't show up for some strange reason.

That's the way SF.NET works. The file was uploaded at the time of the posting but hadn't sent to all the mirrors. Until that sf.net doesn't allow to download as I understand. So, I wrote "posted".

Also curious how the executable in my build takes 11MB and yours is a meagre 2MB.

1. It's 0.74 official sources. I'd make SVN releases if Ykhwong didn't. Also I have not so much time for working on munt itself and definitely have no time on supporting DOSBox+munt... 🙁
2. Both the munt library and the DOSBox are compiled using MS VC 2008 with full speed optimisations and linked with whole program optimisation. So, all the unnecessary code should be removed.
3. The binary contains no debug info.

I used the SVN but it couldn't have been that much of a difference...

Actually, I'm not so sure about this. As the recent Ykhwong build you mentioned causes CPU overload, I suspect some changes were applied to the SVN making the patch we use incompatible.

I recommend using mt32emu driver for Windows as it requires no additional program to launch and can be flawlessly integrated with any DOSBox release or any other MIDI source. This solution I'm able to officially support, test and use myself.

Hmm, just tried Ykhwong's build 20130205 (Windows). Works perfect to me (in terms of speed). Unfortunately, Ykhwong uses quite old munt sources which contain a number of bugs we've recently fixed.

sergm wrote:

marooned_on_mars wrote:

The file doesn't show up for some strange reason.

That's the way SF.NET works. The file was uploaded at the time of the posting but hadn't sent to all the mirrors. Until that sf.net doesn't allow to download as I understand. So, I wrote "posted".

Ah, I wasn't aware of that. ^^

sergm wrote:

1. It's 0.74 official sources. I'd make SVN releases if Ykhwong didn't. Also I have not so much time for working on munt itself and definitely have no time on supporting DOSBox+munt... 🙁
2. Both the munt library and the DOSBox are compiled using MS VC 2008 with full speed optimisations and linked with whole program optimisation. So, all the unnecessary code should be removed.
3. The binary contains no debug info.

Probably the debug was the culprit for bloating the executable and also slowing things down.

I used the SVN but it couldn't have been that much of a difference...

sergm wrote:

Actually, I'm not so sure about this. As the recent Ykhwong build you mentioned causes CPU overload, I suspect some changes were applied to the SVN making the patch we use incompatible.

I suppose, but wouldn't that make things really ugly, like the patch not working at all or failing to produce sound or any other symptom?

sergm wrote:

I recommend using mt32emu driver for Windows as it requires no additional program to launch and can be flawlessly integrated with any DOSBox release or any other MIDI source. This solution I'm able to officially support, test and use myself.

I wish I could use that, but it's as slow as the SVN builds (both mine and ykhwong's) plus that a lack of reverb when recording wav files isn't that useful to what I intend to do...

sergm wrote:

Hmm, just tried Ykhwong's build 20130205 (Windows). Works perfect to me (in terms of speed). Unfortunately, Ykhwong uses quite old munt sources which contain a number of bugs we've recently fixed.

Well that is possible as you might have a faster CPU than me.

marooned_on_mars wrote:

I wish I could use that, but it's as slow as the SVN builds (both mine and ykhwong's) plus that a lack of reverb when recording wav files isn't that useful to what I intend to do...

😕 Completely... You're saying my DOSBox outperform the driver _that much_? Common... Most probably your system is misconfigured if so.

BTW, the driver is _way_ more configurable and the mt32emu_qt app provides much more control over the emulation engine. But I've already written that.

sergm wrote:

Hmm, just tried Ykhwong's build 20130205 (Windows). Works perfect to me (in terms of speed). Unfortunately, Ykhwong uses quite old munt sources which contain a number of bugs we've recently fixed.

marooned_on_mars wrote:

Well that is possible as you might have a faster CPU than me.

Well, it's AMD Athlon II X2 240 @ 2.8GHz. But even underclocked to 800 MHz the sound is still clear and the CPU load is below 33%.

I thunk he hasn't tried the new driver but refers to the ages old driver

sergm wrote:

😕 Completely... You're saying my DOSBox outperform the driver _that much_? Common... Most probably your system is misconfigured if so.

Please elaborate on "misconfigured" ^^;

sergm wrote:

BTW, the driver is _way_ more configurable and the mt32emu_qt app provides much more control over the emulation engine. But I've already written that.

Trust me, I'd rather use the driver, and also I'd prefer it's neat qt-interface with the MT-32 LCD screen and volume control. I tried the latest driver (1.1.1) and while it's better than the previous version that I've tried (1.0.0) it still skips at places. On songs that usually have 2-3 instruments the CPU usage stays around 50%, with no instruments (nothing playing) it drops to ~20%, when there are more "complex" songs playing it raises at 100% resulting in skips. But the skips aren't a problem since they aren't picked up when I record the midi, the problem is when the instruments are "prolonged" when let's say something pops up in the background on the screen and dosbox looses processing power, they are picked up in the midi and that's troublesome since then I'd have to start all over again and I'd much rather avoid that. This doesn't happen with DosBox since it stops recording once emulation is "paused" (and instruments stretched).

sergm wrote:

Hmm, just tried Ykhwong's build 20130205 (Windows). Works perfect to me (in terms of speed). Unfortunately, Ykhwong uses quite old munt sources which contain a number of bugs we've recently fixed.

marooned_on_mars wrote:

Well, it's AMD Athlon II X2 240 @ 2.8GHz. But even underclocked to 800 MHz the sound is still clear and the CPU load is below 33%.

That is quite interesting, I use a low-end CPU (Intel Celeron D... ugh) but still there shouldn't be such a big leap.

Dominus wrote:

I thunk he hasn't tried the new driver but refers to the ages old driver

As explained above I used the newest versions. By pre-1.0.0 that I mentioned earlier I meant the custom DosBox 0.74 builds that were available on GitHub last year before 1.0.0 that I used for a while.

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.

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

sergm wrote:

And I think we'd better move to another thread as this one seems not right for the matter.

Truly sorry about that, I started a thread here.