@keenmaster486 I'm pretty much out of ideas at the moment (and can't find a T41 to test with).
If you play a wav file with media player, and then start a DOS Prompt, is audio still playing normally? What about when you start a DOS game?

Please also install the A04.1 attached in this post. You can adjust buffer= in the .ini (needs a system reboot to apply). Try adjusting that and see if it makes any difference.

@stanwebber can you also try the attached version? First, without any changes, see if the MIDI stutters are gone. Then, in the .ini file, set priority to realtime instead of auto and reboot. Retest if the first note during FM playback is still messed up. Also retest MIDI as well.

Thanks for the Sysinternals process explorer tip, I will use that!

the first fm note still gets mangled with some frequency, but setting priority to realtime has cleared that up 100%. i don't think my experience is the norm though. i've come to discover that my soundcard and/or system is very timing sensitive. it has very little to do with cpu usage as there typically isn't any. what seems to fix the stuttering in most cases is a generous increase to the audio buffers. this has worked for bassmidi (vst), qsynth and munt. timidity++ was a complete mess until i raised its thread priority to above normal. audio in dosbox ece was barely recognizable until the audio blocksize was increased above 4096 (default 512).

it took a heavy lift. but i have most everything adjusted by trial and error so that playback is smooth. as you can imagine, latency is a nightmare. this soundcard is the worst i have ever used and i'm stuck with it.

voplsrv is working as well as it can on my system i think. i also tried it out on an athlon xp kt133a board and the results so far have been good. btw, the install.bat is not updating the new voplsrv ini so i had to manual replace the old one.

Does instaling the WDM Audio update for 98SE (269601USA8.EXE) and/or SweetLow's updated SBEMUL.SYS ( http://sweetlow.orgfree.com/download/sbemul.zip - providing local mirror in case of link troubles) improve things

sdz wrote on 2026-07-16, 17:50:

Please also install the A04.1 attached in this post. You can adjust buffer= in the .ini (needs a system reboot to apply). Try adjusting that and see if it makes any difference.

No difference. All DOS programs and games produce no FM audio at all. OPLWIN32 still working fine. OPLWIN32 also works fine if I run it simultaneously with a DOS program (one that is not trying to write to the OPL2 ports).

Btw DOS games produce PC speaker and SB digitized sounds just fine, so it's not like they're muting the audio output or something.

Thank you!

It is very useful for post 2000 era PCs with WDM drivers. I will test it later with my laptops.

Latest release here: https://github.com/sdz-mods/VOPL3/releases/tag/A05
It's mostly the already attached A04.1, plus some minor changes.

@stanwebber In that case, just keep it set to realtime in the .ini file (I only added auto so it doesn't lock up the system during startup. As that doesn't happen on your system, there is no problem leaving it at realtime). How is the MIDI routing with the new version? Still getting stutters?

@MrMateczko I haven't tried any of those yet. I did take a look at SweetLow's patched SBEMUL.SYS and it doesn't have the correct PE checksum. As is, VOPL3's SBPATCH will refuse to touch it. If anyone wants to try it with SweetLow's patched SBEMUL.SYS, use the attached SBPATCH.exe that will patch it and only give a warning regarding the stale checksum.

@keenmaster486 still out of ideas at the moment, sorry.

@crazii Thank you for SBEMU!
Please let me know how the testing goes.

sdz wrote on 2026-08-02, 09:37:

@keenmaster486 still out of ideas at the moment, sorry.

Well, if it helps and you feel like looking into it further, here's the chip the Thinkpad T41 uses: https://theretroweb.com/chips/3604 (you can find a list of motherboards that have the chip integrated on that page as well)

And here's a list of all the Thinkpads that have that chip: https://www.thinkwiki.org/wiki/AD1981B

no complaints at this point on my win98se 440bx & kt1333a systems with onboard pci ess1978 and cmi8738 wdm drivers. it even plays nice with the isa soundcards on the kt133a systems that have vxd drivers loaded alongside wdm. the kt133a systems will lock up if i try to use the microsoft gs wavetable softsynth, but it works with everything else: munt, vsc, s-yxg100, sw-10, d77, wingroove, wavecube, wavestream, qsynth, timidity, fsmp.

i'm mixing wdm & vxd drivers so i wouldn't be worried about this as it is uncharted territory. besides, vdmsound will work with the microsoft gs wavetable synth for whatever convoluted reason. (the 440bx system with no vxd drivers has no problem with the microsoft gs wavetable softsynth.)

sdz wrote on 2026-08-02, 09:37:

I did take a look at SweetLow's patched SBEMUL.SYS and it doesn't have the correct PE checksum.

Fixed.

Cool. Just FYI, there's not really any reason to maintain both Nuked-OPL3 and Nuked-OPL3-fast builds, other than just to compare the performance improvement -- the output is exactly the same; -fast is just faster, so it's strictly an improvement.

@agovtman I believe you, but there isn't really much effort in keeping them both in. I might also add dbopl (DOSBOX) in the future.

SweetLow wrote on 2026-08-03, 10:10:

sdz wrote on 2026-08-02, 09:37:

I did take a look at SweetLow's patched SBEMUL.SYS and it doesn't have the correct PE checksum.

Fixed.

Just out of curiosity, when using VOPL3, what's the difference between using your DLL and Microsoft's?

i had to stop running this on my kt133a win98se systems. it eventually corrupts the file systems and i had to go thru multiple re-formats and restores before i tracked it down to vopl3 (at least as far back as alpha 5 & 4) and could reproduce the write failures on demand. at times audible crackling can be heard thru the soundcard when files are being copied that is not present when vopl3 is uninstalled. in particular, corruption can be generated when copying certain files from the raid controller to the onboard ide (this is not the infamous via 686x bug). the problem is specific to these systems as i have a 440bx win98se laptop running vopl3 that exhibits absolutely none of this. if you are running iwill kk266+ or kk266+raid boards i would steer clear until the problem can be identified.

matti157 wrote on 2026-08-27, 22:50:

Just out of curiosity, when using VOPL3, what's the difference between using your DLL and Microsoft's?

SweetLow's patch changes 1 byte which makes the emulated sound card report as a Sound Blaster 16 (BLASTER string with T6 instead of T4). It shows up as a Vibra 16XV which only uses one 8-bit DMA channel so you have to edit the config files on Build engine games manually to get 16 bit sound.

stanwebber wrote on 2026-08-30, 14:51:

i had to stop running this on my kt133a win98se systems. it eventually corrupts the file systems and i had to go thru multiple re-formats and restores before i tracked it down to vopl3 (at least as far back as alpha 5 & 4) and could reproduce the write failures on demand. at times audible crackling can be heard thru the soundcard when files are being copied that is not present when vopl3 is uninstalled. in particular, corruption can be generated when copying certain files from the raid controller to the onboard ide (this is not the infamous via 686x bug). the problem is specific to these systems as i have a 440bx win98se laptop running vopl3 that exhibits absolutely none of this. if you are running iwill kk266+ or kk266+raid boards i would steer clear until the problem can be identified.

VOPL3 keeps the audio stream open at all times, playing silence whenever there is no OPL music. I think I already said that was a bad idea because it's unnecessary extra overhead, and if it might be causing corruption it really should be changed.

Besides that though, I think some of the blame needs to lie with VIA. Even the B version of the chipset is known to have problems with PCI sound cards.

@stanwebber Did not have filesystem corruption on my VOPL3 bugs bingo card...

@onethirdxcubed sure, there is some overhead, but at that point it doesn't even hold realtime priority. I don't see how that can cause filesystem corruption, unless there is a deeper issue that is maybe unrelated to VOPL3 (eg. Same corruption happens if media player is opened long enough when doing those file transfers).

here are some specs on the systems suffering the problems:

motherboard: iwill kk266+, iwill kk266+raid
cpu: athlon xp 2000, athlon xp 2100
chipset: kt133a/vt82c686b
onboard audio: cmi8738
isa soundcard: opti 82c924, crystal cs4232
primary storage: ide to sata ssd adapter, ide to cf adapter
via 4-in-1: 4.35v

the failure mode on the system with the cf adapter is very identifiable and repeatable. copying certain files from the onboard hpt370 raid array to certain areas on the os drive located on the cf adapter will cause that adapter to disconnect during the write and not be available until after a hard power cycle. the errors this generates on the fat32 file system can be unpredictable...sometimes completely recoverable by msdos scandisk where only the incomplete copied files are affected versus one time where half the folders under c:\program files were missing. very often there would be issues with invalid long file names which msdos scandisk would complain that only windows disk tools could repair. there always seemed to be audible crackling from my speakers to accompany the problematic file operations whenever vopl3 was installed.

once i found a set of particular files and a destination path that caused the problem i could repeat the failure on-demand over and over again. now, if i took the same set of files and copied them to an alternate destination path on the same drive then moved them to the original path it could work out just fine. something about the composition of source files and destination triggered the disconnects, but i could discern no pattern. file copies would just work until they didn't, but once i found a combination that didn't i could hammer it and get a failure absolutely every single time. needless to say, as soon as i uninstalled vopl3 all such combinations i identified would then successfully copy without issue.

the corruption on the system with the sata adapter was less tangible. twice, i had to reformat and restore because after a time windows would just eventually fail to boot displaying a windows protection error with no changes to the system. given how similar the 2 systems are i find it doubtful that something other than vopl3 is the culprit here despite no smoking gun. vopl3 is uninstalled now and so far so good after 5 days--i'll update this thread if that changes.

any ideas on why this might be happening on these specific systems? i really would like this to work on all my retro builds.

It sounds like the classic VIA 82C686 DMA corruption bug, but I'm surprised it is still happening on the B variant and with ISA sound cards as well. Do you have the George Breese PCI Latency patch installed, are you using VxD or WDM drivers for the CMI 8738 (or not using it at all), and does the corruption still happen with the onboard audio completely disabled? Also does data corruption happen even without VOPL3 if you are playing sound while copying files? Try with something that doesn't require a lot of disk IO like a MOD file or a MIDI through a software wavetable.

no, i've never specifically heard of the george breese pci latency patch, but since the vt82c686? latency issues are so well publicised, isn't the equivalent patch included in the via 4-in-1 chipset drivers (or viapfd105.exe)? i use the cmi8738 with wdm drivers as my primary sound device. the isa soundcards are only used under msdos or for hardware midi in windows.

outside of vopl3 i've not tried pressing the issue by copying files with continuous audio running. (i'm not really anxious to try, but i suppose there should be confirmation). currently, the cmi8738 automatically shares irq 10 with a whole slew of other pci devices (probably storage controllers), but there is a bios setting to assign the pci slot(s) it's tied to manually. would there be any point to do so?

I'll prepare a VOPL3 version that closes the audio stream when the OPL3 engine isn't active. This will likely help on those specific systems, though it won't fix the underlying issue.
As for IRQ sharing under 98, it can indeed cause various issues, depending on the exact hardware, drivers, etc.

The George Breese patch is here: https://www.georgebreese.com/net/software/#PCI

The 4.35 VIA chipset drivers are from November 2001 after VIA admitted there was a problem but people on older forums were still complaining of issues after that date. Maybe you could try version 4.38 or 4.43?

For robustness you should put your hard drives on either the chipset IDE or the RAID controller but not both, and assign the CMI card and storage controller to different IRQs. Also disable any Legacy Sound Blaster support in BIOS if it's there, that would be for VIA's hardware compatibility built into the Southbridge which you aren't using.

I also wonder if there might be some specific issues with VOPL3 when used in a system that has a real OPL on the ISA bus, since I don't think this scenario was tested by SDZ.

You could use a Y cable, 3.5mm to CD ROM header cable, or a mixer to play the ISA card and the CMI at the same time and then you wouldn't need to worry about software OPL.