Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Installation instructions - clarifications #90

Open
knerlington opened this issue Jun 8, 2023 · 6 comments
Open

Installation instructions - clarifications #90

knerlington opened this issue Jun 8, 2023 · 6 comments

Comments

@knerlington
Copy link

knerlington commented Jun 8, 2023

Preface

How to properly install and use DSOAL and OpenAL Soft seems very convoluted. Or rather there's a lot of different statements regarding the installation process so this is an attempt to clarify some things.

General installation truth

DSOAL relies on OpenAL Soft and both have 32/64 bit binaries.
You need both dsound.dll (dsoal) and soft_al.dll (openal soft) where soft_al.dll has to be renamed as dsoal-aldrv.dll.
Drop the corresponding dll files in the directories containing 32/64 bit executables for the games in question respectively.
Clear as day so far, but now it gets a bit messy.

Requirement or convenience/extended configuration?

Some say that you need to install OpenAL Soft in the users %appdata% folder.
More specifically that would be under "appdata\roaming" where you have to create a folder named OpenAL and put the contents of the binary release of OpenAL Soft found here https://openal-soft.org/#download in it.
Is this a requirement? Or is this only if you want to use non-default HRTF tables? Alternatively if this is only needed if you want a user global configuration with one general alsoft.ini file instead of having to create a local one for each individual game?
What's the order of precedence here? I assume local game installation > appdata install.

Troubleshooting/registry solutions or also a requirement?

According to this site/document https://docs.google.com/document/d/1SyOw7D0H2ecGxzPsCFEFKwupU8LuazUrlkI-gVTpyhc/edit
you have to add a total of four registry entries in order to "register" dsound.dll. The actual registry fix here https://www.indirectsound.com/registryIssues.html from what I can gather is primarily used for another DS restoration project called IndirectSound which translates DS calls into XAudio2. Does DSOAL require this registry fix at all? Or are there just cases where it might apply to DSOAL as well? Could it hurt having it?

What does registering dsound.dll mean in this context? As a recognizable name when the dll files are loaded? Is this dependent on having OAL Soft installed in %appdata%?`

OpenAL Soft in System32 and SYSWOW64

Can't remember the source, but I read somewhere that you have to/might have to install soft_al.dll in these locations. Is this true?

FMOD registration via Creative ALchemy

Again taken from here https://docs.google.com/document/d/1SyOw7D0H2ecGxzPsCFEFKwupU8LuazUrlkI-gVTpyhc/edit
In the case of Far Cry there is no fmodex.dll file present in the installation dir for the game. Should there be?

Lastly and also related to ALchemy; Does the dsound.ini file generated from ALchemy in any way affect DSOAL after replacing ALchemy's dsound.dll with the DSOAL one?

DSOAL/ALchemy tip

Just noticed that as soon as you just open ALchemy it replaces dsoal with it's own dsound.dll for ALL games already added in the ALchemy app in it's right column. Meaning you have to install dsoal locally for each game again every time you open ALchemy.

Closing words

While I do think I have a working setup (the dsoal/openal soft log file is generated saying dsoal-aldrv.dll is loaded) with both EAX, DS3D and a preferable HRTF table running in the games I'm currently playing the above sections are still unclear to me. Hope my questions are clear enough to understand what I mean.

Thanks in advance and for preserving one of the most important aspects of gaming.

@kcat
Copy link
Owner

kcat commented Jun 8, 2023

Some say that you need to install OpenAL Soft in the users %appdata% folder. More specifically that would be under "appdata\roaming" where you have to create a folder named OpenAL and put the contents of the binary release of OpenAL Soft found here https://openal-soft.org/#download in it. Is this a requirement?

No. That's not how OpenAL Soft is installed, and %AppData% is only used for system- or user-level custom configuration (alsoft.ini settings), custom HRTF datasets (.mhr files), and custom surround sound decoder presets (.ambdec files).

Alternatively if this is only needed if you want a user global configuration with one general alsoft.ini file instead of having to create a local one for each individual game? What's the order of precedence here? I assume local game installation > appdata install.

Yes, the alsoft.ini settings in the local game directory tag precedence over the alsoft.ini settings in %AppData% (the latter is still loaded, and uses the settings from it that aren't modified in the game-local alsoft.ini).

According to this site/document https://docs.google.com/document/d/1SyOw7D0H2ecGxzPsCFEFKwupU8LuazUrlkI-gVTpyhc/edit you have to add a total of four registry entries in order to "register" dsound.dll. The actual registry fix here https://www.indirectsound.com/registryIssues.html from what I can gather is primarily used for another DS restoration project called IndirectSound which translates DS calls into XAudio2. Does DSOAL require this registry fix at all? Or are there just cases where it might apply to DSOAL as well? Could it hurt having it?

They might be necessary for DSOAL as well (see issue #34, where it seems there's some inconsistency in whether the registry tweaks are needed, or whether they work). It shouldn't hurt to set them for DSOAL any more than IndirectSound or ALchemy.

What does registering dsound.dll mean in this context? As a recognizable name when the dll files are loaded?

It basically tells Windows how and where it can load dsound.dll from when using certain Windows APIs. as I understand it. Without them, it seems certain API calls will only load dsound.dll from the system folder, while setting them lets those API calls load it from the game folder too.

Can't remember the source, but I read somewhere that you have to/might have to install soft_al.dll in these locations. Is this true?

Not for DSOAL. That's for installing OpenAL Soft system wide to enable as another driver for apps that use OpenAL natively (it adds additional "OpenAL Soft on ..." devices to select from). DSOAL uses dsoal-aldrv.dll instead of the system OpenAL, so it's not affected.

Again taken from here https://docs.google.com/document/d/1SyOw7D0H2ecGxzPsCFEFKwupU8LuazUrlkI-gVTpyhc/edit In the case of Far Cry there is no fmodex.dll file present in the installation dir for the game. Should there be?

I don't know the game well enough to say if it should have that DLL or not.

Lastly and also related to ALchemy; Does the dsound.ini file generated from ALchemy in any way affect DSOAL after replacing ALchemy's dsound.dll with the DSOAL one?

No, ALchemy's settings don't influence DSOAL and they don't use the same ini files.

@knerlington
Copy link
Author

No. That's not how OpenAL Soft is installed, and %AppData% is only used for system- or user-level custom configuration (alsoft.ini settings), custom HRTF datasets (.mhr files), and custom surround sound decoder presets (.ambdec files).

Ok so the binaries (soft_al.dll) aren't used or referenced from there, but the folder structure is correct? appdata\roaming\openal. Naming the parent folder OpenAL is just for logical readability?

It basically tells Windows how and where it can load dsound.dll from when using certain Windows APIs. as I understand it. Without them, it seems certain API calls will only load dsound.dll from the system folder, while setting them lets those API calls load it from the game folder too.

Ok so it's the APIs that deduce the location from those key names.

I don't know the game well enough to say if it should have that DLL or not.
Neither my retail copy or digital distro have it so I'm guessing not.
I also guess that the whole fmod dll registration is performed through registry entries made by ALchemy then?

Thanks for replying! Cleared up a lot.

@kcat
Copy link
Owner

kcat commented Jun 8, 2023

Ok so the binaries (soft_al.dll) aren't used or referenced from there, but the folder structure is correct? appdata\roaming\openal.

Correct for the binaries. The folder structure depends somewhat on Windows. "%AppData%" denotes the environment variable "AppData", which is set from the system configuration, so its exact value will depend on the Windows version and system configuration. Modern versions of Windows seem to set AppData to something like C:\users\<username>\AppData\Roaming.

  • For the configuration file, OpenAL Soft/DSOAL looks for %AppData%\alsoft.ini, followed by the alsoft.ini in the same folder as the executable.
  • For the HRTF datasets, it looks for %AppData%\openal\hrtf\*.mhr by default. Though you can change the folder it looks in with the ini, %AppData%\openal\hrtf is just the default.
  • For the decoder presets, they're put in %AppData%\openal\presets\ by default, but the config options for the decoders take a full path, so they can really be put anywhere you want.

@knerlington
Copy link
Author

Ok so the binaries (soft_al.dll) aren't used or referenced from there, but the folder structure is correct? appdata\roaming\openal.

Correct for the binaries. The folder structure depends somewhat on Windows. "%AppData%" denotes the environment variable "AppData", which is set from the system configuration, so its exact value will depend on the Windows version and system configuration. Modern versions of Windows seem to set AppData to something like C:\users\<username>\AppData\Roaming.

* For the configuration file, OpenAL Soft/DSOAL looks for `%AppData%\alsoft.ini`, followed by the `alsoft.ini` in the same folder as the executable.

* For the HRTF datasets, it looks for `%AppData%\openal\hrtf\*.mhr` by default. Though you can change the folder it looks in with the ini, `%AppData%\openal\hrtf` is just the default.

* For the decoder presets, they're put in `%AppData%\openal\presets\` by default, but the config options for the decoders take a full path, so they can really be put anywhere you want.

Sorry for any confusion. I really just meant if the root path following the env. variable where OAL Soft looks for HRTF etc. had to be named "openal". Could have saved you some time. Again - thanks for the clarification!

@mirh
Copy link

mirh commented Jun 8, 2023

where it seems there's some inconsistency in whether the registry tweaks are needed, or whether they work)

As I already argued plenty of times(not that I'm really adamant about being right, but at least the theory went uncontested...)
You need the registry fix if whatever the game you have loads dsound.dll through COM, as opposed to loadlibrary.
On top of that, the original one was only half-assed and it was missing the HKLM keys (which are needed for games run as admin).

Lastly and also related to ALchemy; Does the dsound.ini file generated from ALchemy in any way affect DSOAL after replacing ALchemy's dsound.dll with the DSOAL one?

Half-way related: installing alchemy automatically applies the original partial version of the registry fix, that may contribute to your confusion.

That's for installing OpenAL Soft system wide to enable as another driver for apps that use OpenAL natively (it adds additional "OpenAL Soft on ..." devices to select from).

With the other caveats that I mentioned in #86 (comment)

In the case of Far Cry there is no fmodex.dll file present in the installation dir for the game. Should there be?

I cannot make out any sense out of those instructions. People in #33 and even in #9 (though unsatisfied the with "quality" of the results) didn't have any egregious problem with making dsoal work at all.

@mirh
Copy link

mirh commented Jul 1, 2023

Ok so, just for the records.. Today somebody dropped the far cry sources.
Long story short, the InitSound function loads CrySoundSystem.dll. I couldn't find anything inside its code, except that it links to a certain crysound.lib whose header is authored by "Firelight Technologies Pty".
Unfortunately that's just as much as I could discover about it or crysound.dll...

On the other hand, after following some more the fmodex.dll breadcrumb trail, I found the source is @IDrinkLava
(which makes the case for it exactly with FC1) https://www.youtube.com/watch?v=fgoDXy-Wnj0
According to the comments, "something" that happened to Windows in ~2019 broke FMOD.
This may or may not have been just a plain regular OS upgrade though, as in: I was already suspecting in my last comment here that could reset the HKLM/HKCU keys.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants