First post, by LSS10999
While experimenting with NT 3.51 on some real hardware that I could manage to install and run it, I noticed these audio issues.
1. Sound Blaster 16/AWE can't properly play some WAV files, particularly 16-bit ones. (Only on real systems)
Trying to play such audio files will make the player stuck, and different programs behave differently.
- Some games simply don't care. There would be no audio but the game keeps working, most likely the audio playback routine was asynchronous.
- Sound Recorder will simply stuck at the beginning -- the position slider will not move. It is possible in some cases to get out of the situation by stopping.
- Some games whose audio playback routine is synchronous would find itself freeze on spot, as it keeps waiting for the audio playback to complete which will never happen.
The behavior was originally observed on RUBY-9719VG2AR (LPC-ISA) with a SB16 (CT2950). However, the same behavior is also observed on my currently active NT 3.51 system, ANOVO AIMB-865 (PCI-ISA) with AWE64 Gold (CT4390).
On the other hand, this issue seems to only affect *real* Sound Blaster 16/AWE setups and does not manifest in VMs, such as VirtualBox's Sound Blaster 16 emulation. Additionally:
- Under the same hardware setup, Sound Blaster 16/AWE cards in question will work without problems on newer Windows versions like Win9x, 2000, XP.
- Some non-Creative sound cards like ALS007 can correctly play the files that SB16/AWE could not play properly. ALS007 doesn't use 16-bit ISA DMA channel, however.
- CMI8330 can also play the files correctly, although I need to use NT3.51's built-in SNDBLST driver as I can't properly set up its own NT4 driver (utilizing WSS portion) despite no issues according to Dependency Walker. CMI8330 does use 16-bit ISA DMA channel and is considered a SB16 by the SNDBLST driver.
I'm yet to find the exact cause. Perhaps Windows NT 3.51 likely had issues with 16-bit ISA DMA on relatively modern hardware that were somehow fixed with later Windows versions. It may be possible to work around the issue if the games' sound samples are simple and accessible (e.g. WAV files), by converting the offending sound files to 8-bit (using tools like Audacity). Since the ways games handle audio can be very different, your mileage may vary.
LATE EDIT: It seems to be an issue specific to Creative SB16/AWE, not those from other vendors. With CMI8330, which is fully SB16 compatible including high DMA, this issue does not manifest, just like VirtualBox.
2. MIDI startup delay issue (MCISEQ)
Sadly this MCI issue, which was well-known and already had patches for WinXP/2003, affects old Windows NT versions like 3.51 as well. So it appears pretty much all Windows NT versions are affected by this issue.
The symptom is that whenever a MIDI track finished and a new MIDI track is to start playing, there would be an apparent pause of about 1-2s. For games that use MIDI as background music, gameplay would freeze during the pause period until the next MIDI track actually begins.
By inspecting NT 3.51's MCISEQ.DLL I discovered the very same "Sleep(4)" pattern responsible for this issue. Patched the call into "Sleep(0)" as in the linked blog post and the pause disappeared.
I'm attaching a patched MCISEQ.DLL for Windows NT 3.51 in case someone's interested. For other Windows NT versions you need to open MCISEQ.DLL with a reverse engineering utility and search for relevant "Sleep" calls. Per the linked blog post, the Sleep call with value "4" passed into it, as well as being coupled with "LeaveCriticalSection", would be the likely candidate.