DSOAL, a DirectSound replacement that gives old games surround sound and EAX

What the DLL actually does

DSOAL is a DirectSound DLL replacement. It implements the DirectSound interfaces by translating the calls to OpenAL, and it fools applications into thinking there is a hardware accelerated sound device. EAX is also implemented, up to version 4, by using OpenAL's EAX extension, which allows for environmental reverb with sound obstruction and occlusion effects.

The README summarises the effect in one line: it allows DirectSound applications to enable their DirectSound3D acceleration path and turn on EAX, with the actual processing done by OpenAL and no hardware acceleration requirement, so it works on systems where audio acceleration is not otherwise available. The short version is that it enables DirectSound3D surround sound and EAX for systems without the requisite hardware.

The trick is the second half of that description. An application from the DirectSound era checks for DirectSound3D support at startup, and if it is not present it silently falls back to mono with no effects, often with a notice in a configuration file that nobody reads. A replacement DLL that reports the full feature set changes which code path the application takes, which is why this approach works at all where a simple output device swap would not.

That is the whole design in one sentence, and it explains both the value and the limits. The application gets the effects it was written to produce, and they are computed by OpenAL in software.

The project is LGPL-2.1 licensed, written in C++, on the master branch, with the last push on 2026-10-20. The releases are tagged by content rather than by number: latest-master for the current DSOAL r697 with OpenAL Soft r10852, and an archive tag for a build archive.

Building it and how the files have to be laid out

Building the source needs CMake 2.6 or newer, and the README gives two ways to do it.

There is the CMake GUI, where you specify the source directory and the directory for the build files, and there is the command line, where you make sure you are in an empty directory where the build files should go, such as the provided build/ sub-directory, and run cmake with the path to the source. The emphasis on an empty directory is a real constraint rather than a formality, because CMake caches configuration in the build directory and reusing a populated one produces confusing errors.

Once the build succeeds it produces dsound.dll, and the deployment rules are specific.

The DLL goes in the same location as the target application's executable. You also have to provide an OpenAL DLL in the same location, named dsoal-aldrv.dll, or the DLL will fail to work. The naming is not arbitrary: the DirectSound replacement loads the OpenAL driver by that name so it can find it next to itself rather than searching the system path, which is what makes the whole thing work as a local drop-in.

There is one more configuration step the README mentions, and it is the one that trips people up. Some applications need to be configured to use DirectSound3D acceleration and EAX, which usually means a configuration file or an in-game option telling the game that hardware acceleration is available. After that it works the next time the application is run.

The README also points at the source releases and Windows binaries for OpenAL Soft, available on the OpenAL Soft homepage, with instructions there. So the practical dependency chain is DSOAL plus an OpenAL Soft build, and the two have to be matched, which is why the release tags name both versions: DSOAL r697 with OpenAL Soft r10852.

The repository layout shows a project with the usual mixed-platform pieces: CMakeLists.txt, src/, a build/ directory, a fmt-11.2.0/ vendored formatting library, .clang-tidy, an appveyor.yml for Windows CI, and separate module definition files for MinGW and for MSVC in 32 and 64 bit.

Diagnosing the silent failure case

The two environment variables solve a specific diagnostic problem, and it is worth being precise about what the problem is.

The common failure with a DLL replacement is not a crash. It is silence. The game starts, it plays, and the surround effects are simply absent, because the application took the fallback code path. There is no error message, no dialog and nothing in the game's own logs, because from the application's point of view everything worked as designed on a machine without accelerated 3D audio.

That is why DSOAL_LOGLEVEL exists as a documented setting rather than only as a debugging convenience. The default of 1 reports errors only, which is right when the game is running and you are trying to play it. The useful setting is 3, which enables logging of API traces, so you can see the DirectSound calls arriving. If the trace file is empty, the replacement was never loaded and the problem is deployment: the DLL is in the wrong directory, or the game resolves DirectSound from a location you did not put the file in, or the game is loading it by absolute system path.

The log file behaviour matters for the same reason. DSOAL_LOGFILE names a file that is created or overwritten on each execution, so the file always reflects the current run rather than the history. For a one-shot diagnosis that is exactly right, since a stale file from an earlier attempt tells you nothing. If you are watching a long session and want to keep the history, you have to copy the file between runs.

And the EAX version limit is the other thing to know before you try this. EAX is implemented up to version 4, so applications that use later effects will get the subset rather than the full set. Combined with the software rendering, the practical result is that a scene with heavy occlusion and reverb costs CPU that the game would rather spend on rendering, and the frame rate can dip where real hardware would not have.

None of that stops the tool doing its job. A DirectSound game from the era that checks for DirectSound3D support and silently falls back is exactly the case this exists for, and on a system with no hardware acceleration at all it is the only way to hear the effects the game was written to produce.

The environment variables and where this fits

Two environment variables control the behaviour, and they exist because the first symptom of this approach is silence.

DSOAL_LOGLEVEL takes an integer from 0 to 3 and sets the verbosity of DSOAL logging. Level 3 enables logging of API traces, and the default is level 1, which reports errors only. So by default you get error messages and nothing else, which is right for a game you are playing and wrong for a first attempt where you need to know whether your replacement DLL was loaded at all.

DSOAL_LOGFILE takes a path. The file will be created or overwritten by DSOAL on each execution, and all logging is redirected there. If it is unset, logging goes to the process's stderr output.

The overwrite behaviour is worth noting if you are using it to watch a long session, because the file reflects the current run rather than the history of them.

Together, the two variables give you the diagnostic you need in the common failure case. The common failure is that the game loads the system DirectSound instead of your replacement, often because the DLL is in the wrong directory or because the game uses a different naming convention, and a log level of 3 writing to a file will show the DirectSound calls arriving. Without that, the game simply has no surround sound and you have no way to tell whether the replacement is loaded.

The comparison to make is with the alternatives for enabling these effects. Modern games use XAudio2 or WASAPI and have their own HRTF implementation, and nothing here applies. Emulators such as the ones built on Wine or Alsa have their own translation layers for DirectSound, with overlapping goals and different constraints. And there is the option of not having the effect at all, which is where many people end up because the effort to configure a replacement DLL is not worth it for a single game.

What DSOAL does better than the alternatives is fidelity to the DirectSound interface itself. An emulator translating DirectSound to ALSA is doing something similar but without implementing the DirectSound3D and EAX surfaces that the application is specifically checking for, so the game still takes the fallback path. A replacement DLL is the only approach that changes what the application believes about the hardware.

The limitation is the software rendering. Without hardware acceleration, a busy scene with several occluding sources and environmental reverb costs CPU that the game would rather spend elsewhere, and the frame rate may dip where it would not with real hardware. The EAX implementation goes to version 4, so later effects are out of scope by definition.

Editorial conclusion

Adopt DSOAL if you play a DirectSound era game that has no modern audio path and you want its surround and reverb effects working in software. Skip it if the game already uses OpenAL, XAudio2 or WASAPI, since the replacement only helps applications that call DirectSound. Verify first by building the DLL, placing it and the OpenAL Soft library beside the game executable, and running with DSOAL_LOGLEVEL set to 3 to confirm the application is actually loading the replacement rather than the system DirectSound.

Frequently asked questions

Official sources

1. Issues
2. kcat/dsoal on GitHub
3. License: LGPL-2.1
4. README
5. Releases