Hi guys, I've spent a few days putting a patch together for Sierra audio drivers that might be of use to others. I know there are already many patches of various kinds, but this one is new and relevant, as it fixes some issues that remained unsolved to date. This patch can be applied after other existing patches, and is fully compatible with them.

First of all, a little background. Over the last couple of months, I've slowly been setting up my "dream 486" machine for my kids. It's a physical machine, no dosbox, running a 486DX2, with an ESS1869 AudioDrive + Gravis Ultrasound Max + MT-32 + CM-500 + SC-55, loaded with over 200 of my favourite games from my childhood, plus a few others I didn't get a chance to play back then but wanted to experience. I've completed that project, but the very last game I got to caused me some real grief - the CD release of "The Incredible Machine 2". Due to overlapping bugs/issues in this game, on my hardware, I could only get Midi/synth music with no speech, or speech with no music at all. I'll be posting separate topic soon with some specific patches for "The Incredible Machine 2" around speech files (to get speech without the CD), but this thread is about the general problems with Sierra audio drivers, which affect a bunch of Sierra games, but are crippling on this game in particular if you have ESS hardware. This bug would also severely impact you on many Sierra titles if you are using an ESS1868/1869 based device with a Wavetable device, either onboard or via a daughterboard, including with modern popular devices like the X2GS Waveblaster or the MK1869 sound card.

I noticed during configuring my 486 box for this large range of games, that a number of Sierra titles (and only Sierra titles) made the audio output from my ESS1869 card quieter when I ran them. This lower volume level persisted after closing. It turns out the games were resetting the mixer registers, so any changes I'd made in ESSVOL.EXE at startup were being blown away. I'd taken to adding a call to ESSVOL.EXE on close in the run scripts for the affected games to restore them, and resigned myself to adjusting the speaker volume knob up/down when running these games. It was an annoyance, but that was all. Until "The Incredible Machine 2", which I introduced my daughter to and she absolutely loves. This game uses CD audio, if the CD is in the drive. At least, it's supposed to. If you're running an ESS chipset though, despite the CD spinning, you hear no music, because the game resets the mixer registers on launch, and the CD mixer registers default to 0! Now, this mixer register reset problem is a known issue, it's been discussed here a few times before. I found these mentions:
Advice for Getting Midi to Play in Sierra Games?
Re: Gabriel Knight 1 - General Midi/MT-32 Not Working.
MIDIto r12 (Midi and FM redirection, Mixer locking, Sound Blaster fixes)

These threads identify the problem, and propose a fix by using a TSR called MIDIto, to intercept port access and "lock" mixer register changes. That's fine, if you're happy to run in Virtual 8086 mode, but I'm of the opinion that V86 mode sucks. It probably doesn't matter too much if you're running in a VM with an effective 300MHz processor, or you're using some late-gen system with a 100+MHz processor and a PCI bus, but if you're using a straight-up DX2 at 66MHz, V86 mode hurts performance noticeably, with all that monitor code running on what's supposed to be quick interrupt handlers or memory/port access. With some careful memory management and appropriate launch scripts, I've got every killer title from the days of DOS running without EMM386 loaded, and I don't want to enable V86 mode just for the sake of a dodgy line of code in a sound driver. I'm a software developer with 25 years of experience, who's done a lot of hardware reverse engineering and written my own emulators, so I took this issue as a challenge and decided I was going to fix it. It took me a bit to locate the two remaining brain cells which remembered how to drive SoftIce, and I had to re-live the trauma that is the developer experience of x86 real mode, but after a bit of bashing and debugging I had the issue identified and a patch prepared. I'll just dump in the notes from my patch script here now:

1# 2025-05-17 - Created by Nemesis
2# This patch searches for audio drivers for DOS-era Sierra games, and patches them to fix two key issues:
3#
4# 1. Audio mixer volumes reset on game launch when using ESS 1868/1869 hardware (and possibly others)
5#     On affected Sierra audio drivers, if the BLASTER environment variable is not defined, or that variable does not
6#     contain a defined high DMA value of 4 or higher, the driver will attempt to read from mixer register 0x81, mask
7#     off its top 3 bits, and write it back again during audio initialization. The original intent is not clear,
8#     however mixer register 0x81 is not a valid register number on any hardware. On ESS devices, register accesses
9#     wrap around at 0x80, so attempted access to reg 0x81 is treated the same as 0x01. Register 0x01 is also
10#     undefined on all hardware, however on ESS devices it is treated the same as access to register 0x00, which
11#     means a mixer reset is performed when the write occurs. This resets all the volume settings for all inputs and
12#     outputs, overriding any settings previously set by ESSVOL.EXE. For FM output, this will often result in Sierra
13#     games sounding softer when they run, requiring you to adjust your speaker volume when they play, and re-run
14#     ESSVOL.EXE after the game closes. If you are using a Wavetable device however, mixing inputs from line in, or
15#     the game uses CD audio like the CD version of 'The Incredible Machine 2', a mixer reset completely mutes the
16#     CD and AuxB outputs and LineIn, making it impossible to hear these audio sources with ESS devices on Sierra games.
17#
18# 2. Audio mixer volumes reset on game close on all hardware
19#     This is a deliberate choice rather than a bug like the above issue, but a useless annoying one. Sierra audio
20#     drivers do not intentionally change the mixer audio settings during gameplay from what I have observed. None
21#     the less, the drivers will often deliberately reset the mixer registers when closing by writing 0x00 to register
22#     0x00. If the driver read, stored, and restored the original mixer settings that would be fine, but doing a full
23#     reset of the mixer, despite not having changed the volume levels, just destroys any configuration which was done
24#     by ESSVOL.EXE, or the equivalents for any other hardware vendor. Extension registers, such as PC speaker volume
25#     settings in the case of ESS1869 hardware, are also reset by this behaviour. This patch removes the mixer reset
26#     when the application closes. This means Sierra games can now be run without needing to restore your mixer
27#     settings after they exit, which is how all other observed games (that I've seen in 200+ games) behave.
28#
29# Notes:
30# - Patched files will have a corresponding backup file created, IE, 'AUDBLAST.DR_' will be the backup for 'AUDBLAST.DRV'.
31# - Backup files will only be created if they do not currently exist, making this safe to run multiple times over the
32#   same files.
33# - In order to fix issues with Dyanmix games such as 'The Incredible Machine 2', the GOSiERRA v3 patch must be run
34#   first. See below for more info on this.

In a nutshell, the behaviour of the mixer registers getting messed with on launch is a clear bug, not intended behaviour. This patch fixes that bug. There was also pointless intentional resetting occurring of the mixer settings on close. This patch removes that behaviour. You can still call ESSVOL.EXE after close to change settings, but the default will now be to (correctly) assume you want your audio settings to remain as you set them.

Anyway, to run this patch, download the attached python script (take off the .txt, vogons doesn't allow .py files directly as attachments), and run it in the same directory as the game you want to patch, or in a higher directory, as it'll scan recursively down the tree, or provide a target directory on the command line as an argument. The list of games I know require patches at this time is as follows:
Gabriel Knight 1
Police Quest 4
Quest for Glory 4
Space Quest 4
Space Quest 5
Space Quest 6
Space Quest 6 Demo
The Incredible Machine 2
Note that other Sierra titles will certainly be affected, but I don't have them all installed. In particular I haven't tested on any Leisure Suit Larry titles or King's Quest titles after 5. Based on the linked threads, it seems likely you can add Freddy Pharkas and Leisure Suit Larry 6 to this list, but someone would have to test to confirm that. My patch will backup the original files, so 'AUDBLAST.DRV' will be backed up to 'AUDBLAST.DR_' if you want to revert later.

I kept the patch in python since it's transparent and self-documenting. If someone has a question about this 10 years from now, if I just drop an opaque 16-bit binary, that's going to be a PITA. This script on the other hand does everything using a few regex expressions. As a python script, you won't be able to run this from dos, but once the files are patched you just need to transfer them onto your DOS machine. This patch is fully compatible with all existing audio patches that have been released, and in fact you MUST run the GoSiERRA Patch v3 first if you want to patch 'The Incredible Machine 2' (http://sierrahelp.com/Utilities/SoundUtilities/GOSiERRA.html) or reportedly other "Dynamix" releases such as 'Betrayal At Krondor', as this earlier patch will extract the compressed sound drivers to make them available to my patch program. Ignore the various ".drv" files in the folder for those releases, they're not the real files, just old, dummy ones to keep the INSTALL.EXE program happy so it can find and allow you to switch between them. The game ignores the external .drv files and uses its internal ones (yes, really).

Anyway, that's about it. Let me know if there are any questions or issues.