SoundAPI: OpenAL backend

[LAGonauta]

This PR implements an OpenAL backend to Cemu. I've tested it on Linux and on Windows, but other platforms need testing.

Reasoning

Whenever surround sound is available, I like to enable headphone 3D audio spatialization, however I've been using Moonlight on Android and in my experience surround sound has extreme audio lag in that platform. Each input has a 1 second audio delay or so, which is quite bad. Stereo works wonderfully, though.

Through OpenAL I can enable 3D audio spatialization (HRTF) support in OpenAL Soft's config and transmit the audio in Stereo, ensuring low latency.

When playing locally, audio latency with OpenAL Soft is comparable to Cubeb, and I added a concept of "Target Latency" that automatically resamples the audio to maintain one to three blocks buffered at all times. Unlike XAudio2 which allows it to grow to 24 blocks and then start dropping them to maintain acceptable audio lag.

As a bonus, if you are one of the lucky few to have access to a sound card with hardware OpenAL support you should expect undetectable audio lag.

Notes

Instead of downloading the OpenAL headers through vcpkg I included them in the branch. I can't say I know what is best. I can change it to vcpkg if you feel it is better to do it that way.

Additionally, in this change set I load the library dynamically to not require OpenAL to be instead in the user's system even when support is compiled in, it is an optional dependency. I think it is sane to do this as other backends are always available.

I am available for any questions and I will maintain this backend for the long term, if not here in my branch.

[LuismaSP89]

I'm curious about this PR. One of my WiiU's favorite games (Zombi U) has audio issues because Cemu is capable only to play this game in stereo, and there's a lot of missing sounds ingame.

In the original WiiU you need to change the output in the system for this game, from 2.0 to 5.1 in order to play it with all the sounds, but if I do this in Cemu by booting the system (WiiU OS) this makes no difference. Maybe this PR fix this, we will see : )

[capitalistspz]

The non-vcpkg dependencies are usually in https://github.com/cemu-project/Cemu/tree/main/dependencies

[Exzap]

Can you help me understand how exactly OpenAL fixes your issue and why a solution can not be implemented on a lower level so that it works for the other backends. Asking because from what I understand, OpenAL (soft) nowadays is just implemented via translation to a lower audio API and I fail to understand how OpenAL can achieve something that those APIs can't. I am assuming you are not running a setup where there is actual hardware support for OpenAL, if thats even a thing anymore.

I'm curious about this PR. One of my WiiU's favorite games (Zombi U) has audio issues because Cemu is capable only to play this game in stereo, and there's a lot of missing sounds ingame.

This PR doesn't fix it. The issue you describe is a problem in the HLE audio emulation core (sndcore) which is not touched by this PR.

[LAGonauta]

Can you help me understand how exactly OpenAL fixes your issue and why a solution can not be implemented on a lower level so that it works for the other backends

When you say lower level, you mean driver level? Closer to the hardware? Solutions exist for Windows (HeSuVi) and for Linux (Pulseaudio Virtual Surround), however I couldn't get them to work together with Moonlight. User error? Probably. They work perfectly locally, however. I also wonder how those post-processing effects would compare to OpenAL Soft regarding audio latency.

For Windows there is also spatial sound, but the HRTF profiles offered by it does not really match my own profile so it can be difficult for me to discern where the sound comes from.

As I mentioned in my PR, Moonlight for Android supports transmitting 5.1 audio. My phone supports virtualisation through Dolby Atmos, and my S-XFI AMP has its own 3D audio virtualisation built-in. However, even with Oboe the audio latency is stratospheric. Not usable in my view. It is not a Moonlight/Sunshine problem, it is an Android problem. Sometimes I wish it supported PulseAudio...

nowadays is just implemented via translation to a lower audio API

You are correct, so it goes like this:

Application -> OpenAL Soft -> OpenAL audio effect engine -> Native audio sink

In this use case the "OpenAL audio effect engine":

1. Mixes with other sources into a single stream (not applicable to Cemu as we only have one source. OK, two if you count the gamepad)
2. Apply audio effects (like reverb, not applicable to Cemu)
3. Apply audio spatialization (HRTF for headphones, so Surround to Stereo. Or audio spatialization for different speaker configurations)
4. Automatically resamples the audio to the native audio sink
5. Finally, outputs the processed audio

Of course, the native audio sink can be anything. WASAPI, PortAudio, AAudio, PulseAudio, ALSA...

I am assuming you are not running a setup where there is actual hardware support for OpenAL, if thats even a thing anymore.

It is not a thing anymore. I happen to have a proper hardware solution, but it only works locally which is not what I need due to Sunshine/Moonlight anyway. I can capture and pipe the DSP output manually to another audio device, it would satisfy my use case but this is not ideal due to increased complexity and audio latency.

I fail to understand how OpenAL can achieve something that those APIs can't

XAudio can achieve something like OpenAL Soft (see here), but I am not aware of anything like that for Cubeb. Does it have an effects API built-in, that can apply HRTF to the audio?

If by lower-level you mean Cemu itself doing 3D audio virtualisation processing, there were some talks of splitting OpenAL Soft's effect engine from the project, so projects that do not care about the OpenAL API can just use the engine instead. This would allow Cemu to apply HRTF effects to the audio while implementing its own sinks, but I am not sure how that splitting project is going. I am not aware of any other library that can apply spatialization.

In the end, what OpenAL offers really is a multi-platform effect engine and output solution, so every platform and headphone/speaker system Cemu supports can enjoy deterministic 3D audio spatialization.

Sorry, I ended up writing too much. I can ramble sometimes. I hope this answers your question, if not just ask again and I may try again lol

I understand this is quite a niche use case, especially if Cemu for Android stabilizes and performs well. So if you feel Cemu does not need Yet Another Audio Backend feel free to reject this PR :)
As I said, I will maintain it myself so it is not really a problem to me.

[Exzap]

If by lower-level you mean Cemu itself doing 3D audio virtualisation processing, there were some talks of splitting OpenAL Soft's effect engine from the project, so projects that do not care about the OpenAL API can just use the engine instead. This would allow Cemu to apply HRTF effects to the audio while implementing its own sinks, but I am not sure how that splitting project is going. I am not aware of any other library that can apply spatialization.

This is imho the way to go. You should look into spearheading a separate HRTF library yourself because OpenAL being deprecated for 15 years is certainly not making it easy to convince new projects to adopt it. I think OpenAL soft has quite a permissive license so you should be able to just start with their HRTF code and go from there. Anyway this is just a suggestion.

From our perspective I am against merging this because it's one more backend to worry about for very little benefit. Cubeb already is a decent solution for cross-platform audio. OpenAL is not only deprecated, it also comes with a ton of baggage that we don't need (Cemu really only cares about raw audio output, all the mixing is done in the emulation core).

That said, I appreciate the effort and the detailed explanations. High quality PRs like this are rare :)