Feature Request: OpenAL backend

[ensiform]

Would like to have some additional feature parity by having OpenAL support. Maybe improved from ioquake since it had limitations?

VoIP can be excluded for now unless you want it

[ghost]

Currently I have a Q3e fork using openal (eventually + efx + voip + vorbis) and I'm a bit hesitant if it is worth to add openal support to Q3e at all. Is this still something of interest? Are there any other suggestions concerning OpenAL-Soft support?
@ensiform I inspected a few games and how there implementation is done, but I still don't see which one is the 'best', or better than the one from ioquake3. To me quake2xp isn't really much better as well (referring to etfdevs/ETe#6).
Speed comparisons gives me neither more nor less FPS using openal-soft vs. dma sound. I also tested Q3e with Openal + enabled efx effects using boomstick (Q3Reaction) mod with compiled efx contents, and it works well.
Since I saw that @BidyBiddle managed to get dmaHD working with Q3e I would also highly appreciate his opinion about the current Q3e sound status.
@ec- What do you think about Openal-Soft support?
Any suggestions are welcome!

[ensiform]

I can't just drop in whatever you come up with for quake3e because there's significant portions of ET sound features that need to be implemented as well.

[ghost]

You mean scripted speaker (volume/range). Music streams, etc.
If I have a basic concept I consider to make a seperate PR for ETe considering the necessary API differences (trap calls).
If you want you can also make some special requests for ETe, though it would be also okay if ETe will use a different implementation than Q3e. I just thought it would be recommended that both (Q3e and ETe) stay close to each other. Extending the API shouldn't be too hard. The AL-efx effects are API independent. Thanks for the response!

[ensiform]

Scripted stuff is all cgame really. It's the volume control, fading, different flags and other features with channels that must be used.

[ghost]

None of the things you mentioned is causing troubles with OpenAL soft (with the exception of fading stereo sounds, but this is not Q3e/ETe related). Special API calls should work fine, I even saw the 'lip-sync' feature (RtCW) fixed recently.
Or is your statement a suggestion to implement OpenAL the way ioq3 did it? This way it's granted that all idtech3 engines are supported. I can confirm that basically all of these API calls are supported by OpenAL-Soft: https://github.com/zturtleman/spearmint/wiki/id-Tech-3-Engine-Features#New_cgame_to_client_calls-2 (ET API sound related overview).

[ensiform]

It's not a trouble with openalsoft but must be implemented in snd_openal as well so I have lot more work unless I straight up copy etl. I'm well aware they can be supported but it's the implementation I'm avoiding doing that work

[ec-]

@ec- What do you think about Openal-Soft support?

Very, very skeptical

[ghost]

Thx