Proton: [Feature Request] integrate dsound-openal for 3D audio in older titles

[Vaporeon]

dsound-openal is a project aiming to reimplement EAX in software and lately is has gotten really really good when paired with recent openal-soft.
The project repo is here:
http://repo.or.cz/dsound-openal.git

[eandry77]

It also may fix bunch of games with no sound without workaround like https://github.com/ValveSoftware/Proton/issues/177

[mirh]

I'm not sure why proton should start, not just to support, but even enhance Windows games.

On the other hand wine is sure in need of fixes, but that will have to go upstream https://github.com/ValveSoftware/wine/issues/2
(@kcat freenode still don't let me post a thing, you should check it)

[kcat]

Depending on what you mean by enhance Windows games. The main goal with DSOAL (dsound-openal) is essentially emulate hardware audio capabilities older titles could take advantage of. Games like Halo, GTA 3/Vice City, and F.E.A.R. would utilize EAX 2, 3, and 4 through DirectSound3D, which would be available with certain hardware cards of the time. Similarly, some hardware cards supported forms of HRTF, which can be restored through OpenAL Soft's HRTF. So it wouldn't really be enhancing Windows games, more like restoring the full capabilities that may have available to older titles during their time.

It's a double-edged sword, though. Ever since Windows Vista, hardware audio for games has largely been killed off (save for some games that use OpenAL with Creative's hardware drivers), so few post-XP games would be expecting accelerated DirectSound and may get confused if they find it. And while there could be a switch to disable hardware emulation, DSOAL's advantages drop off quickly after that and the may even start to become a liability. Its main advantage at that point would be having a fully fledged decent-to-high quality audio mixer ready and available to use, but Wine's current implementation may be "good enough" for titles that don't need what DSOAL offers.

[mirh]

I'm talking about your comment of "making a push to get wine to use openal soft for directsound and xaudio".
They are going in an opposite direction and you may want to have a talk.

[kcat]

Ah, well I made that comment before learning about FAudio, and the developers' clear interest in using it. I can't really say they're wrong, a ground-up implementation focusing on accuracy to the original xaudio would seem to be a nicer prospect than trying to mold an external API into behaving a specific way for their needs.

I can certainly reach out and talk to them about it, but I wouldn't imagine their plans changing much in this regard. An OpenAL Soft-based wrapper could offer some nice capabilities (and in cases where such a wrapper does work, the result is generally quite good if not preferable), but as a general solution I can understand why it wouldn't be the most desirable option given compatibility concerns.

[mirh]

So, focus on directsound /s
How would you see that getting implemented instead?
I mean.. considering everything more complex than playing a wav seems getting to be copied so well already from openal.

[flibitijibibo]

Adding to Chris' list, Splinter Cell: Chaos Theory is the title I usually run for testing EAX support. If per-game support is a concern, the registry stuff in the staging patchset is probably worth looking at for whitelisted games, and it wouldn't be too different from ALchemy's old system of configuring each game individually.

https://github.com/wine-compholio/wine-staging/tree/master/patches/dsound-EAX

Having support for EAX2-4 would be cool though! FAudio covers XAudio2/XACT3 (we could also cover XAPOFX but I don't know if anyone's ever used it) but DSound/DSound3D is totally out of our territory, so if any replacement happened, DSOAL is definitely the candidate for that.

(btw @kcat, thanks for the advice early on when I was starting FACT, couldn't have done it without you!)

[kcat]

So, focus on directsound /s
How would you see that getting implemented instead?
I mean.. considering everything more complex than playing a wav seems getting to be copied so well already from openal.

There is the other thing. OpenAL Soft is more than just the OpenAL API. The core lower-level routines for mixing, filter and effect processing, applying property updates, etc, could (with a bit of work) be wholly separated out to a separate static library, then different APIs like OpenAL or DirectSound or whatever can be implemented on top of it. That way an implementation of DirectSound wouldn't be beholden to the OpenAL API to get OpenAL Soft's benefits. Where something like the OpenAL or DirectSound APIs guarantee a measure of safety and higher-level functionality (e.g. continuous uninterrupted output, not crashing the process), a lower level API would be more flexible with the understanding that its callers need to be more careful about what they do.

Perhaps this could be my next project after OpenAL Soft 1.19. Redesign the internals to create a reusable lower-level lib separate from OpenAL itself.