Make EAX an optional dependency

[Kaffeine]

[CrossVR]

There's still an OpenAL backend that we can port to Linux, right?

[Kaffeine]

Yes. The point is that we have EAX code everywhere. E.g. https://github.com/OpenXRay/xray-16/blob/ai_cleanup/src/xrSound/SoundRender_Core.h#L74 I started to ifdef it out, but found that some components (https://github.com/OpenXRay/xray-16/blob/ai_cleanup/src/xrSound/SoundRender_Environment.cpp) probably needs to be rewritten.

[ghost]

Perhaps OpenAL could be replaced with OpenAL Soft, that way those wanting EAX-type effects can emulate them without even using EAX, plus it has some nice feature sets.

[Kaffeine]

OpenAL Soft is the only implementation for Linux and there is no any issues so far.

Even more: "EAX should be considered deprecated as a developer interface. New development should use OpenAL's EFX interface" https://en.wikipedia.org/wiki/Environmental_Audio_Extensions#Future_development

I didn't investigated it yet, but probably this way we would bump required OpenAL version together with hardware, required for effects. I don't care much, as there is no EAX for Linux.

IIRC wine have some EAX emulation, but I could not find the sources ATM.

[tamlin-mike]

Perhaps we should rather identify WHAT in EAX is actually used. Room-echo (requires 3D geometry)? Reverb (for horrible tin-can memories, think of Half Life)?

I'm pretty much 100% sure the code for it is already either in the public domain, or at least free enough for our use. If not, I'll write it. :-)

[revolucas]

@Swartz27 OpenAL32 module already auto loads any *oal.dll it finds. You can add OpenAL Soft device to the list simply by placing soft_oal.dll in bin directory. This is a known work around for ages in getting 5.1 surround to work in CoP.

But why is 5.1 broken for some people? I think there is an issue with how two "Generic Software" show up in the list. The selected sound device is stored in user.ltx and most likely is loading the incorrect one.

[ghost]

@revolucas Correct, if you were to use soft_oal it works fine.

I think the reason to adopt OpenAL Soft though is for cross-platform reasons if I'm not mistaken.

In terms of how much EAX is used in Call of Pripyat, I don't believe EAX actually gets used at all. Someone would need to open the levels in the level editor and see if any sound-based space restrictors which are meant for EAX effects are placed anywhere.

Also, in order for people to be able to, for example, select their sound card as a playback device instead of software emulation, there are a few lines related to OpenAL log features that need to be removed from OpenALDeviceList.cpp

[mirh]

Even more: "EAX should be considered deprecated as a developer interface. New development should use OpenAL's EFX interface"

I mean, by the same "official" token openal is a deprecated developer interface too.

IIRC wine have some EAX emulation, but I could not find the sources ATM.

https://github.com/ValveSoftware/Proton/issues/372#issuecomment-415807989 (which shouldn't be nonetheless all that complete)

I'm pretty much 100% sure the code for it is already either in the public domain, or at least free enough for our use.

I don't think it's public domain, but at least the sdk of 2.0 version stalker seems to support is widely available.

[Xottab-DUTY]

Yes, I think we should use OpenAL-Soft instead of deprecated OpenAL. And we don't need EAX, since it\s deprecated and we have EFX nowadays =)

[mirh]

OpenAL-soft is still openal I mean. Then afaiu everything that's eax has a corresponding in efx, yes.

[galeksandrp]

We can actually include https://github.com/bibendovsky/eaxefx, if not yet.

Yes, it is EFX API wrapper with EAX API, used it with all S.T.A.L.K.E.R. games.

[mirh]

The thing may even have wrapped one api into another (because they are kinda meant to map together), but the true difficulty was getting all the advanced effects supported with any in the first place. And now EAX is straightaway included inside openal-soft.

So, like.. You don't really need to even do anything? (not that you had to begin with.. what was this issue even about? making it optional at build time?)

[Xottab-DUTY]

This issue was solved in 97f720cbedf897b1a86fef79f1a2eeec00509229.

making it optional at build time?

Thanks for the reply! I've forgot about this issue :D Yes, the task was making it optional at build time.

[mirh]

Oh, right I see.. Of course in linux you wouldn't be able to link eax.lib.