EAX sound option: "I am confusion?"

[Sir Player One]

So, from my understanding, EAX is an environmental audio effects/virtual surround sound software originally exclusive to SoundBlaster sound cards, but can be seperately used in modern versions of Windows using OpenAL. My question is this: does the current Steam version of System Shock 2 come with everything you need to make EAX work out of the gate? Or do I need to download OpenAL and/or mods to get it to work? Is EAX even worth using?

[Thermal Lance]

You need to install OpenAL. Then select it in the options menu.

[Sir Player One]

Originally posted by Thermal Lance:

You need to install OpenAL. Then select it in the options menu.

I assume it doesn't matter where OpenAL is installed, correct? Never mind, install was stupidly easy. Thanks for the extremely timely response, by the way.

[Tonkinese]

use alchemy use a search engine to find and it was used with and still used with physical sound cards and creative hardware

[Sabin Stargem]

Originally posted by Sir Player One:

Never mind, install was stupidly easy. Thanks for the extremely timely response, by the way.

To be clear, did you install OpenAL, or OpenAL Soft? The latter is far newer and still receives updates.

https://openal-soft.org/


Also, you can use this Youtube video to help figure out which HTRF is right for you.

https://www.youtube.com/watch?v=VCXQp7swp5k

[Sir Player One]

Originally posted by Sabin Stargem:

Originally posted by Sir Player One:

Never mind, install was stupidly easy. Thanks for the extremely timely response, by the way.

To be clear, did you install OpenAL, or OpenAL Soft? The latter is far newer and still receives updates.

https://openal-soft.org/


Also, you can use this Youtube video to help figure out which HTRF is right for you.

https://www.youtube.com/watch?v=VCXQp7swp5k

Bog standard OpenAL, I believe. Would going to OpenAL Soft make a huge difference in performance? I only wanted it to access SS2's EAX option.

[Sabin Stargem]

Originally posted by Sir Player One:

Bog standard OpenAL, I believe. Would going to OpenAL Soft make a huge difference in performance? I only wanted it to access SS2's EAX option.

OpenAL ceased development around 2009, and OpenAL Soft took up the mantle from there. It should be more compatible with Windows 10, along with having extra features. Here is a small part of a changelog:



Updated library codebase to C++14.
Implemented the AL_SOFT_effect_target extension.
Implemented the AL_SOFT_events extension.
Implemented the ALC_SOFT_loopback_bformat extension.
Improved memory use for mixing voices.
Improved detection of NEON capabilities.
Improved handling of PulseAudio devices that lack manual start control.
Improved mixing performance with PulseAudio.
Improved high-frequency scaling quality for the HRTF B-Format decoder.
Improved makemhr's HRIR delay calculation.
Improved WASAPI capture of mono formats with multichannel input.
Reimplemented the modulation stage for reverb.
Enabled real-time mixing priority by default, for backends that use the setting.
It can still be disabled in the config file.
Enabled dual-band processing for the built-in quad and 7.1 output decoders.
Fixed a potential crash when deleting an effect slot immediately after the last source using it stops.
Fixed building with the static runtime on MSVC.
Fixed using source stereo angles outside of -pi...+pi.
Fixed the buffer processed event count for sources that start with empty buffers.
Fixed trying to open an unopenable WASAPI device causing all devices to stop working.
Fixed stale devices when re-enumerating WASAPI devices.
Fixed using unicode paths with the log file on Windows.
Fixed DirectSound capture reporting bad sample counts or erroring when reading samples.
Added an in-progress extension for a callback-driven buffer type.
Added an in-progress extension for higher-order B-Format buffers.
Added an in-progress extension for convolution reverb.
Added an experimental Oboe backend for Android playback.
This requires the Oboe sources at build time, so that it's built as a static library included in libopenal.
Added an option for auto-connecting JACK ports.
Added greater-than-stereo support to the SoundIO backend.
Modified the mixer to be fully asynchronous with the external API, and should now be real-time safe.
Although alcRenderSamplesSOFT is not due to locking to check the device handle validity.
Modified the UHJ encoder to use an all-pass FIR filter that's less harmful to non-filtered signal phase.
Converted examples from SDL_sound to libsndfile.
To avoid issues when combining SDL2 and SDL_sound.
Worked around a 32-bit GCC/MinGW bug with TLS destructors.
See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83562
Reduced the maximum number of source sends from 16 to 6.
Removed the QSA backend.
It's been broken for who knows how long.
Got rid of the compile-time native-tools targets, using cmake and global initialization instead.
This should make cross-compiling less troublesome.


Don't really understand much of that myself, but I will assume that OpenAL Soft beats OpenAL by a country mile.

[Sir Player One]

Originally posted by Sabin Stargem:

Originally posted by Sir Player One:

Bog standard OpenAL, I believe. Would going to OpenAL Soft make a huge difference in performance? I only wanted it to access SS2's EAX option.

OpenAL ceased development around 2009, and OpenAL Soft took up the mantle from there. It should be more compatible with Windows 10, along with having extra features. Here is a small part of a changelog:



Updated library codebase to C++14.
Implemented the AL_SOFT_effect_target extension.
Implemented the AL_SOFT_events extension.
Implemented the ALC_SOFT_loopback_bformat extension.
Improved memory use for mixing voices.
Improved detection of NEON capabilities.
Improved handling of PulseAudio devices that lack manual start control.
Improved mixing performance with PulseAudio.
Improved high-frequency scaling quality for the HRTF B-Format decoder.
Improved makemhr's HRIR delay calculation.
Improved WASAPI capture of mono formats with multichannel input.
Reimplemented the modulation stage for reverb.
Enabled real-time mixing priority by default, for backends that use the setting.
It can still be disabled in the config file.
Enabled dual-band processing for the built-in quad and 7.1 output decoders.
Fixed a potential crash when deleting an effect slot immediately after the last source using it stops.
Fixed building with the static runtime on MSVC.
Fixed using source stereo angles outside of -pi...+pi.
Fixed the buffer processed event count for sources that start with empty buffers.
Fixed trying to open an unopenable WASAPI device causing all devices to stop working.
Fixed stale devices when re-enumerating WASAPI devices.
Fixed using unicode paths with the log file on Windows.
Fixed DirectSound capture reporting bad sample counts or erroring when reading samples.
Added an in-progress extension for a callback-driven buffer type.
Added an in-progress extension for higher-order B-Format buffers.
Added an in-progress extension for convolution reverb.
Added an experimental Oboe backend for Android playback.
This requires the Oboe sources at build time, so that it's built as a static library included in libopenal.
Added an option for auto-connecting JACK ports.
Added greater-than-stereo support to the SoundIO backend.
Modified the mixer to be fully asynchronous with the external API, and should now be real-time safe.
Although alcRenderSamplesSOFT is not due to locking to check the device handle validity.
Modified the UHJ encoder to use an all-pass FIR filter that's less harmful to non-filtered signal phase.
Converted examples from SDL_sound to libsndfile.
To avoid issues when combining SDL2 and SDL_sound.
Worked around a 32-bit GCC/MinGW bug with TLS destructors.
See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83562
Reduced the maximum number of source sends from 16 to 6.
Removed the QSA backend.
It's been broken for who knows how long.
Got rid of the compile-time native-tools targets, using cmake and global initialization instead.
This should make cross-compiling less troublesome.


Don't really understand much of that myself, but I will assume that OpenAL Soft beats OpenAL by a country mile.

Fair enough, I'll check it out. Thanks for the info.

[Sir Player One]

Originally posted by Sabin Stargem:

Originally posted by Sir Player One:

Bog standard OpenAL, I believe. Would going to OpenAL Soft make a huge difference in performance? I only wanted it to access SS2's EAX option.

OpenAL ceased development around 2009, and OpenAL Soft took up the mantle from there. It should be more compatible with Windows 10, along with having extra features. Here is a small part of a changelog:



Updated library codebase to C++14.
Implemented the AL_SOFT_effect_target extension.
Implemented the AL_SOFT_events extension.
Implemented the ALC_SOFT_loopback_bformat extension.
Improved memory use for mixing voices.
Improved detection of NEON capabilities.
Improved handling of PulseAudio devices that lack manual start control.
Improved mixing performance with PulseAudio.
Improved high-frequency scaling quality for the HRTF B-Format decoder.
Improved makemhr's HRIR delay calculation.
Improved WASAPI capture of mono formats with multichannel input.
Reimplemented the modulation stage for reverb.
Enabled real-time mixing priority by default, for backends that use the setting.
It can still be disabled in the config file.
Enabled dual-band processing for the built-in quad and 7.1 output decoders.
Fixed a potential crash when deleting an effect slot immediately after the last source using it stops.
Fixed building with the static runtime on MSVC.
Fixed using source stereo angles outside of -pi...+pi.
Fixed the buffer processed event count for sources that start with empty buffers.
Fixed trying to open an unopenable WASAPI device causing all devices to stop working.
Fixed stale devices when re-enumerating WASAPI devices.
Fixed using unicode paths with the log file on Windows.
Fixed DirectSound capture reporting bad sample counts or erroring when reading samples.
Added an in-progress extension for a callback-driven buffer type.
Added an in-progress extension for higher-order B-Format buffers.
Added an in-progress extension for convolution reverb.
Added an experimental Oboe backend for Android playback.
This requires the Oboe sources at build time, so that it's built as a static library included in libopenal.
Added an option for auto-connecting JACK ports.
Added greater-than-stereo support to the SoundIO backend.
Modified the mixer to be fully asynchronous with the external API, and should now be real-time safe.
Although alcRenderSamplesSOFT is not due to locking to check the device handle validity.
Modified the UHJ encoder to use an all-pass FIR filter that's less harmful to non-filtered signal phase.
Converted examples from SDL_sound to libsndfile.
To avoid issues when combining SDL2 and SDL_sound.
Worked around a 32-bit GCC/MinGW bug with TLS destructors.
See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83562
Reduced the maximum number of source sends from 16 to 6.
Removed the QSA backend.
It's been broken for who knows how long.
Got rid of the compile-time native-tools targets, using cmake and global initialization instead.
This should make cross-compiling less troublesome.


Don't really understand much of that myself, but I will assume that OpenAL Soft beats OpenAL by a country mile.

Wait, how exactly do I install OpenAl Soft without borking everything? The readme in the binaries zip isn't super clear. I'm on a 64 bit system, so I don't know if I need to copy both of the DLL files to the indicated destinations, or just the latter one. And what about the rest of the zip's contents?

[Sabin Stargem]

Originally posted by Sir Player One:

Wait, how exactly do I install OpenAl Soft without borking everything? The readme in the binaries zip isn't super clear. I'm on a 64 bit system, so I don't know if I need to copy both of the DLL files to the indicated destinations, or just the latter one. And what about the rest of the zip's contents?

I believe that OpenAL Soft uses two DLLs, one to add compatibility for 32-bit games, and the other for 64-bit stuff. System Shock 2 is before 64-bit computing became public, and likely needs the 32-bit file. Modern stuff like Minecraft may require the 64-bit DLL.

Anyhow, I recommend installing both files - they are differently sized, therefore the contents and workings are different. Copy the DLLs from the folders into the specified locations.


Win32 folder (soft_oal) -> C:\Windows\SysWOW64
Win64 folder (soft_oal) -> C:\Windows\system32


You can drop the contents of the archive anywhere you wish - I will use the Desktop as an example as needed. From there, go into alsoft-config and run the .exe to use the configuration GUI to set up finer details. The decoder files are located in the "presets" folder. I think this is the appropriate order?

Rectangle
itu5
Hexagon
3D7.1

I recommend using Thief's Bafford mission to test the surround-sound. Just go over to a wall and listen to the guard conversation to see if you can tell their position by ear.


OPTIONAL
Once done, you may use openal-info32/openal-info64 to confirm that the computer recognizes the DLLs. To run the executables, you need to manually open the command prompt. Typing "command" in your Windows search bar should show you a shortcut to it.

Inside the command window, use "cd C:\Users\XXX\Desktop\OpenAL Soft", to enter the directory. You will need to substitute XXX with your profile name. Now you enter "openal-info32" or "openal-info64", to check for the respective DLL status.
/OPTIONAL

[Sir Player One]

Originally posted by Sabin Stargem:

I believe that OpenAL Soft uses two DLLs, one to add compatibility for 32-bit games, and the other for 64-bit stuff. System Shock 2 is before 64-bit computing became public, and likely needs the 32-bit file. Modern stuff like Minecraft may require the 64-bit DLL.

Anyhow, I recommend installing both files - they are differently sized, therefore the contents and workings are different. Copy the DLLs from the folders into the specified locations.


Win32 folder (soft_oal) -> C:\Windows\SysWOW64
Win64 folder (soft_oal) -> C:\Windows\system32


You can drop the contents of the archive anywhere you wish - I will use the Desktop as an example as needed. From there, go into alsoft-config and run the .exe to use the configuration GUI to set up finer details. The decoder files are located in the "presets" folder. I think this is the appropriate order?

Rectangle
itu5
Hexagon
3D7.1

I recommend using Thief's Bafford mission to test the surround-sound. Just go over to a wall and listen to the guard conversation to see if you can tell their position by ear.


OPTIONAL
Once done, you may use openal-info32/openal-info64 to confirm that the computer recognizes the DLLs. To run the executables, you need to manually open the command prompt. Typing "command" in your Windows search bar should show you a shortcut to it.

Inside the command window, use "cd C:\Users\XXX\Desktop\OpenAL Soft", to enter the directory. You will need to substitute XXX with your profile name. Now you enter "openal-info32" or "openal-info64", to check for the respective DLL status.
/OPTIONAL

Very helpful, thank you ever so much! Funny enough, I don't actually own a copy of Thief, even though it would be right up my alley and is cheap (or presumably free, from the right sources) to get. I'll try to remember to keep an ear out whenever I get around to grabbing a copy. I don't have a surround sound system either, so any surround effect would have to be virtual. Now, for setting up HRTF in the alsoft-config GUI, do I have to specifically direct the HRTF profile paths to the "hrtf_defs" folder in the OpenAL Soft archive, or does the "Include Default Paths" checkbox do that for me? Or am I misunderstanding setting that up? Thanks again for all your help.

Edit: My attempt to enter the directory in command prompt failed, it couldn't find the indicated path. Don't know why, maybe because yours is installed on the desktop and mine isn't? Not sure about how to figure out where mine should direct.

Nevermind, I'm a big dumbo, took me a minute figure out that "duh, it's directing to the archive's location".

[Sabin Stargem]

Originally posted by Sir Player One:

Very helpful, thank you ever so much! Funny enough, I don't actually own a copy of Thief, even though it would be right up my alley and is cheap (or presumably free, from the right sources) to get. I'll try to remember to keep an ear out whenever I get around to grabbing a copy.

Now, for setting up HRTF in the alsoft-config GUI, do I have to specifically direct the HRTF profile paths to the "hrtf_defs" folder in the OpenAL Soft archive, or does the "Include Default Paths" checkbox do that for me? Or am I misunderstanding setting that up? Thanks again for all your help.

If you are interested in using the GOG store, you can buy the Thief trilogy at a huge discount right now - about $3.30 or so.

Thief Gold at GOG[www.gog.com]


From my experimentation, OpenAL Soft doesn't come with compiled HTRF tables. I recommend fetching the HTRF files inside of the DSOAL zipfile, which has a "hardmode" zip that contains the actual HTRF files. Create and fill a HTRF folder inside of the OpenAL Soft directory, then setting it as your HTRF folder.

DSOAL Mod[www.nexusmods.com]


A lot of fuss and bother we go through for our games. Still, it is nice to know when someone is around the the left corner.

[Sir Player One]

Originally posted by Sabin Stargem:

If you are interested in using the GOG store, you can buy the Thief trilogy at a huge discount right now - about $3.30 or so.

Thief Gold at GOG[www.gog.com]


From my experimentation, OpenAL Soft doesn't come with compiled HTRF tables. I recommend fetching the HTRF files inside of the DSOAL zipfile, which has a "hardmode" zip that contains the actual HTRF files. Create and fill a HTRF folder inside of the OpenAL Soft directory, then setting it as your HTRF folder.

DSOAL Mod[www.nexusmods.com]


A lot of fuss and bother we go through for our games. Still, it is nice to know when someone is around the the left corner.

Alright, we should be all set to fly, unless there's any other features and/or settings not already mentioned that I should know about. I thank you once again for your thorough help and patience. Fuss and bother indeed, but you made it relatively easy, which I appreciate. Regardless, I'm sure it'll be worth the work in the end, if it can make things that much more engaging.

[RussianSeppukuE03]

Technically OpenAL can only provide EAX if your sound card supports it. ALSoft instead has it's own builtin feature called EFX, which is universal and hardware agnostic. NewDark has the ability to remap it's EAX (and A3D) effects to EFX, but only NewDark has this ability. This is why Creative ALchemy and DSOAL exist, to remap to these effects on games without this ability. This is also why getting EAX 5.0 on BioShock and Doom 3 is a real PITA, as not only does DSOAL not support EAX 5.0 (yet), it also only supports Direct Sound restoration. Yes, DSOAL remaps Direct Sound to OpenAL, but it doesn't restore OpenAL's support directly unfortunately. Vanilla OpenAL does have a builtin wrapper that translates from OpenAL to Direct Sound called wrap_oal.dll that can be used to wrap to ALchemy. That wrapper was originally used to allow OpenAL games to at least run on cards that didn't have a native implementation of OpenAL (think like graphics vendors) by piggybacking on Direct Sound. Wrapping from OAL -> DS -> OAL isn't very efficient nor elegant, but it's this best method for restoring EAX 5.0 effects on games that use OpenAL for anyone who doesn't have a creative card.
Just thought I'd mention this to clear up some misconceptions for anyone who reads this.

[Sir Player One]

Originally posted by RussianSeppukuE03:

Technically OpenAL can only provide EAX if your sound card supports it. ALSoft instead has it's own builtin feature called EFX, which is universal and hardware agnostic. NewDark has the ability to remap it's EAX (and A3D) effects to EFX, but only NewDark has this ability. This is why Creative ALchemy and DSOAL exist, to remap to these effects on games without this ability. This is also why getting EAX 5.0 on BioShock and Doom 3 is a real PITA, as not only does DSOAL not support EAX 5.0 (yet), it also only supports Direct Sound restoration. Yes, DSOAL remaps Direct Sound to OpenAL, but it doesn't restore OpenAL's support directly unfortunately. Vanilla OpenAL does have a builtin wrapper that translates from OpenAL to Direct Sound called wrap_oal.dll that can be used to wrap to ALchemy. That wrapper was originally used to allow OpenAL games to at least run on cards that didn't have a native implementation of OpenAL (think like graphics vendors) by piggybacking on Direct Sound. Wrapping from OAL -> DS -> OAL isn't very efficient nor elegant, but it's this best method for restoring EAX 5.0 effects on games that use OpenAL for anyone who doesn't have a creative card.
Just thought I'd mention this to clear up some misconceptions for anyone who reads this.

This is an interesting clarification. I had no idea just how lacking of support there is for older audio implementations on newer systems. Funny enough, I have a Creative sound card (found it in a dumpster along with the rest of my original system, long story), but I don't have it installed any longer because all of it's software lacks Windows 10 support due to the card's age. It still technically works, but you're pretty much locked out (as far as I could tell) of accessing any of it's features. I'm not even sure if older games like Doom 3 would still be able to recognize it in that case, and use its features. I've never tried, though, so I could be wrong.