Cxbx-reloaded: HLE OpenAL-Soft Option Support

[blueshogun96]

I've noticed that there's been some more increasingly common issues with DirectSound lately, and the API is definitely showing it's age, just like Direct3D8 has been for quite some time. Now, I use OpenAL-Soft quite often, and it's far less troublesome than DirectSound has been in my experience. Now, there's a handful of reasons why I am suggesting this over DirectSound (see below).

1. Simpler API that seems (to me at least) to more closely match the Xbox DirectSound API. Only one listener, no need to create a separate IDirectSoundBuffer3D instance, etc.
2. Buffer creation is far less painful and less error prone.
3. Buffer resizing for Xbox ADPCM should be less of an issue. I noticed that we can't properly play the entire sound buffer when this codec is used because IDirectSound::CreateSoundBuffer() fails when you try to resize it after decoding it.
4. DSP and environmental audio effects. It's low priority, but several games do take advantage of this (JSRF being one of them).
5. Open source and easier to debug. Cross platform too.
6. MUCH better support for audio streams. With OpenAL-Soft, you can queue buffers and get notifications as to when they finish. Currently, Cxbx lacks (and always HAS lacked) proper audio packet streaming. This is a separate issue altogether which I should write up also.

So I'm curious as to what you all think of this? Seems to me like it would be an easy enough transition to make (if you guys see fit). But of course I understand that LLE is a greater priority, but even then, I'd still rather use OpenAL-Soft for that.

Shogun

[PatrickvL]

Be aware the current HLE DSOUND code is quite big, and relies on patching class vmt's. I'd rather see less of that (and even more preferably LLE based audio emulation).

[PatrickvL]

My experience with D3D tells me it'd be best to run most Xbox code unpatched, and instead of interfering, emulate things from the outside (either from only a few select initiating function patches, or entirely from hardware accesses)

[LukeUsher]

Note that for LLE audio emulation, OpenAL is potentially overkill. If we emulate the sound hardware properly, it will simply generate audio samples the same way hardware does: All we would need is some way to play samples from memory, we wouldn't be taking advantage of any functionality OpenAL offers.

Even for the DSP, we will (eventually) emulate the hardware, since Xbox games have the ability to upload code to the DSP, simulating it might not cut it!

[LukeUsher]

Closing as this probably won't happen: The HLE is pretty mature nowadays with DSOUND and the effort to migrate to an alternative isn't worth the time it takes.

LLE APU emulation will be mostly software based, since we need to emulate DSPs and execute their instruction code uploaded by the running title, so a library such as OpenAL won't help that much either. (See above comment)

[blueshogun96]

We'll see if M$ doesn't break DSOUND completely, that is.

Shogun

[winterhell]

Afaik both DSound and OpenAL-soft internally use WaveOut(winmm.dll) which in turn on Vista+ is emulated/routed through WASAPI.
From what I gather WASAPI is supposed to be cleaner, with better latency and video/audio sync features.

[RadWolfie]

Since we are going to support cross-platform, OpenAL-Soft is going to be a requirement for HLE emulation.

[RadWolfie]

Be aware the current HLE DSOUND code is quite big, and relies on patching class vmt's. I'd rather see less of that (and even more preferably LLE based audio emulation).

For others to understand, DSOUND is split into 3 main classes. Each one has several different child classes which are usually constant changing and are black area to expose their, child classes, APIs. Unlike D3D only has one class (and maybe 1 very small child class?). This is part of the reason why it's easier to unpatch D3D than DSOUND.