Ignoring for a moment that doppler has been supported in Q3 engines since 2000 anyway, it really makes me cringe to see uninformed people touting OAL as an "upgrade" to ANYTHING, just because of its name. Pasting from a post of mine from our engine forum about a year ago:
(apologies for Wall Of Text if it comes out that way: /. seems to want to use HTML whitespace consolidation even in POT mode)
As some of you have noticed, over the years we've gone from "openal is off by default" to "openal is excluded from builds" to, finally, "openal is removed completely".
In many ways, this irritates me a lot. I like the CONCEPT of openal, and I especially like the idea that we could have HRTF etc in hardware someday "for free", and ideally I'd like to make oal the ONLY sound backend we supported and get rid of the "ugly" direct-DMA stuff.
There's just one tiny problem: openal simply isn't very good.
As I mentioned in the 1.43 notes, we've made some very significant speedups in the last year or so, and sound is one of the key contributors to that (aside from actually, yknow, WORKING properly now too :P). With my standard config, there's now NO difference in timedemo rates between having full sound and disabling it completely. If you've been around Q3 for a while, that's pretty staggering. Even if I drop to a quarter of that resolution and essentially take the graphics card out of the equation, the numbers are 478 fps with sound disabled, and ... 474 with it on.
That's 96 channels, and they're ALL used when timedemoing "four".
I tried one of the openal test programs, and clocked it at ~6% CPU, which I'd probably just about be willing to accept, except that it was only mixing 64 channels, and the entire thing was static (i.e. this is an absolute "best possible case", where it could potentially pre-mix to an absurd degree because it wasn't doing any dynamic spatialisation).
6% CPU vs 0% CPU, for 64 channels rather than 96, puts it *at a minimum* at ~10% CPU overhead when you're talking apples to apples, and that's not very encouraging. I don't expect it to MATCH cnq3's sound code by any stretch, but that's a pretty big difference and it's even worse if it IS using lazy spatialisation.
There are also questions about how "timely" it is. If positioning etc only updates 30 times a second, or sounds don't actually start playing until 50-100ms after they're added, that's fine for WoW but absolutely shit for Q3. There's no guarantees in the oal spec, or even ANY documented indication of what the "reference" implementation's behavior is, which means we'd have to wade through a bunch of (frankly, pretty sloppy and mediocre) code to actually find out. I have no intention of moving to oal just to end up spending weeks fixing it for Creative.
There are several other issues too: the bug that Q4 has with looped sounds is a direct result of bad design that would have to be worked around at the app level; likewise, oal requires app-level culling of sounds despite the fact that the app CANNOT do so correctly because only the oal implementation actually knows what the 0-volume falloff distance for any given sound is. That's just utterly incompetent design/implementation.
Happily, Timbo (ioq3's developer) was kind enough to run the tests for me, and the numbers very nicely match the observations I've made here:
131.6 fps 2.0/7.6/35.0/3.6 ms no sound
113.5 fps 3.0/8.8/82.0/5.4 ms dma
104.1 fps 3.0/9.6/72.0/5.7 ms openal
So, "normal" Q3 sound (with some of our fixes from 141/142) is about 16% slower than no sound, which is historically what you'd expect; and oal is another 9% slower than that (while mixing only 2/3 as many channels, so the truth is more like 14%, for a total of ~30% slower than cnq3).
And that's why we no longer support oal at all.
I MAY someday revisit this. I doubt there are too many cases where the "missing" 32 channels are actually going to matter, simply because if there's THAT much noise where you are, you're not going to be able to pick the "extra" sounds out. Where that falls down is if it loses IMPORTANT sounds because it decides to play a gnat farting 2000 units away instead: and again, this is something that WE prioritise correctly ATM but oal has no mechanism for.
I could, potentially, create a "non-shit oal" dll that didn't have the performance problems, extend the spec/api/implementation to support priorities, fix the culling bugs, and so on, but I just don't find it a particularly interesting field and I have better things to do.
I MIGHT even be willing to put up with the performance TBH, but I'd still have to either work around the bugs at the app level or fork oal to fix it, which doesn't really benefit anyone, and again, is a waste of my time.
Obviously, just saying "screw it" and switching to oal anyway when it's so inferior in every way is as unacceptable to me as a player as it is to me as a developer, regardless of how much I'd LIKE to do so in the abstract, and that leaves me in a Catch-22. We can't switch to oal until it sucks less; and it won't suck less until someone actually fixes it, which apparently nobody is going to do unless it's us. (Creative, obviously, couldn't care less because their attitude is "buy a Fatal1ty Extreme Super Audigy Z5 Pro III Platinum Deluxe", which I'd actually be really happy to if it had HRTF and worked with Q3, but it won't because, Catch-22 again, we won't support oal in its current state).
So, in a nutshell, OpenAL is:
A Nice Idea, but
Slow as hell
Does not, and CANNOT, actually work correctly for several critical real-world scenarios because of some huge (and blatant) flaws in its design
It's important to understand that this doesn't mean it's unsuitable for EVERY game: I'd probably be perfectly willing to put up with the crapness for something like an RPG or an RTS, where the poor performance isn't especially meaningful; and you can make arbitrary decisions about cutoff ranges; and having sounds just randomly Not Actually Play (which is, yknow, kind of the whole POINT of a sound lib in the first place...) isn't the end of the world. But for a skill-based MP FPS game, OAL is the worst possible option there is.