sdz wrote on 2026-07-11, 22:12:

@keenmaster486 thanks for testing!

Can you run install.bat again, don't reboot, go to C:\VOPL3 and rename VOPLSRV.EXE to TEST.EXE, reboot, then open an MS-DOS Prompt and run TEST.EXE?

After doing that, the system does not hang, but attempting to use the OPL emulation results in this weird stuttering behavior:

@onethirdxcubed it would have helped if I was calling OPL3_WriteRegBuffered instead of OPL3_WriteReg ....
Can you give this one a go please? https://github.com/sdz-mods/VOPL3/releases/tag/A03

@keenmaster486 can you try the above A03? Also, when installing, try to use the Nuked-OPL3-fast backend first (same as before, rename it before rebooting and manually start it after reboot).

installed alpha 2 using the nuked-opl3-fast engine. voplsrv idles just fine until music is actually played in a windows dos prompt, but then it continues to consume resources even after exiting. cpu utilization is roughly 30% on my p3 850mhz. i'll try out the new alpha 3, but maybe this wasn't addressed yet?

you patched sbemul...maybe you can answer this question: why is sbemul restricted to the microsoft gs wavetable sw synth? it's obviously redirecting traffic to the windows midi mapper since changing to something other than the microsoft gs wavetable sw synth renders midi mute until you switch it back. to work around this i currently use vdmsound for win9x which redirects midi at the specified port to any device in the windows midi mapper. vdmsound also has adlib emulation, but is horribly buggy so i disable everything except mpu-401 emulation which is rock solid.

@standwebber that is likely on me. Please try the attached version, uninstall the previous version and install this one. (this is based on A03, and the VOPLSRV is not compatible with the A02 VXD).
Can't really test on my machine as on that I7, the CPU load is about the same with or without VOPLSRV running. But this might fix the issue. (I will set up a more proper machine for testing at some point).

As for SBEMUL, I'm no expert in it, just patched it so it leaves the FM ports alone. But that is something worth looking into. Not sure if we can convince SBEMUL to use something else (I suspect not), but maybe take a similar approach to VOPL3 and patch SBEMUL to leave 330/331 alone, make a VXD trap followed by some steps that I don't know now as I'm not really familiar with this.

Thanks, the latest version works much better with Adlib Tracker and most games that I tried. No more missing notes. Hocus Pocus works with the music set to "Adlib" but not "Sound Blaster" and SBVGM player only works when specifying -opl3388 on the command line which I think is because the Sound Blaster mode writes to the other set of FM ports which are not trapped yet.

Oh and it also works well enough to play Adlib without lagging on a 1.6 ghz Atom netbook running Windows ME. I've had a few crashes trying to get that working though but probably most of that is just WinME being unhappy with existing at all.

Note: on Windows Me you MUST disable System Integrity Protection before installing or it will undo the changes to sbemul.sys

stanwebber wrote on 2026-07-12, 14:11:

installed alpha 2 using the nuked-opl3-fast engine. voplsrv idles just fine until music is actually played in a windows dos prompt, but then it continues to consume resources even after exiting. cpu utilization is roughly 30% on my p3 850mhz. i'll try out the new alpha 3, but maybe this wasn't addressed yet?

you patched sbemul...maybe you can answer this question: why is sbemul restricted to the microsoft gs wavetable sw synth? it's obviously redirecting traffic to the windows midi mapper since changing to something other than the microsoft gs wavetable sw synth renders midi mute until you switch it back. to work around this i currently use vdmsound for win9x which redirects midi at the specified port to any device in the windows midi mapper. vdmsound also has adlib emulation, but is horribly buggy so i disable everything except mpu-401 emulation which is rock solid.

Sbemul was written before DirectMusic so it uses the MidiOut API and it only plays to the Default Device. It also doesn't support timestamps which is why the tempo goes ropey when things lag a bit. I tried to disassemble it with Ghidra but didn't get very far. It's not necessarily true that it will only play to the GS Wavetable Synth; on sound cards with a hardware OPL but using WDM drivers, it will route MIDI to the real OPL (but then it's using the FatMan patch set so doesn't always sound like you would expect, and nothing else can use the hardware OPL).

I was able to get VDMSound for Windows 98 to work with at least the newer EmuAdlib and EmuSbCompat from the 2.10 version and I've put it up here: https://github.com/andrew-hoffman/vdmsound
To make more improvements I would need to disassemble or replace the port-trapping VxD though and that was again my sticking point. I'm not very familiar with x86 Assembly and haven't had much time to learn lately.

@sdz, vopl3ins did the trick. voplserv only consumes resources when midi is playing even if the dos prompt is still open.

I tried VOPL3INS and now I get no audio from it at all.

Still having to kill VOPL3SRV if it loads on startup, still loading fine manually.

Btw yes it would be nice if this thing trapped ports 220-223 as well.

@onethirdxcubed awesome, thanks for testing! I will look into trapping the other FM ports a bit later (not sure how happy SBEMUL will be about grabbing those).
Atoms of that era are quite.. bad (I have some). Glad to hear it's working there. Very good point about ME's System Integrity Protection. I have never used ME, so I had no clue about that. I will that that to the readme file.

Speaking of ME, do you know if it supports USB MIDI class devices? Also (if yes), has anyone tried bringing that to W98SE?

@stanwebber nice! The fix will be included in the next release.

Regarding SBEMUL being restricted to the MS GS synth, I have something in the works for that. Just need to iron out some random freezes and only open the MIDI device when actually needed (so one can use it with normal Windows applications as well). Unlike OPL3 (for which which we only pause the engine while there is no input for a certain amount of time and the output is quiet), here we need to actually close the MIDI device, and we can't use a timeout for this (because if there is enough silence in the game, it will close the MIDI device while still in game). Will try to follow onethirdxcubed 's earlier suggestion and monitor the DOS VM lifecycle to handle that.

@keenmaster486I will prepare a new build and a debug build.

New release https://github.com/sdz-mods/VOPL3/releases/tag/A04

Changelog:
- Fixed idle CPU usage: the renderer stops synthesizing while the OPL3 chip is silent
- Realtime priority is now held only while actually needed (OPL3 emulation or MIDI routing active); normal priority otherwise.
- Added optional MPU-401 MIDI bridge (selectable at install): traps ports 0x330-0x331 and routes DOS-program MIDI to any installed MIDI device.
Configured via the new [midi] section in VOPL3.INI:
[midi]
; 65535 = Windows MIDI Mapper (default) - follows Control Panel >
; Multimedia > MIDI. 0,1,2,... = a specific device index.
device=65535
The MIDI device is opened only while a program is sending MIDI and is released as soon as its DOS box closes (or after 30s of MIDI silence. Not yet 100% sure about this last one, is there an usecase where a Windows application would touch 0x330-0x331?), so it stays available to other Windows applications.
- Added VOPLCFG, an optional control-panel / system-tray app: change the FM volume and the MIDI output device live (no restart), and view driver/renderer status, revisions and debug counters. Can autostart minimized to the tray (asked at install).
- Reinstalling no longer requires stopping VOPL3 manually: INSTALL.BAT stops the running renderer/control panel first.

With the new release, the following items changed:

1. System now loads from startup without having to kill and manually restart VOPLSRV
2. VOPLSRV now produces sound

However, I am still getting that weird stuttering behavior. It plays one tiny snippet of audio over and over and then moves on to the next one.

Attached is an image of VOPLCFG after I exited Commander Keen 4:

@keenmaster486:
-how does the CPU usage look in idle? Is there anything running in the background eating CPU cycles?
-can you try the attached exe? Does it play without stutters?

sdz wrote on 45 minutes ago:

@keenmaster486:
-how does the CPU usage look in idle? Is there anything running in the background eating CPU cycles?
-can you try the attached exe? Does it play without stutters?

CPU usage is zero when idle.

I tried that exe and it played all the way through, but with regular stutters about every half second.

That's useful insight. Uninstall existing VOPL3 and install attached test version. Please report if it's better, worse, unchanged or fixed.