I dont know if you are aware of arqon's attitude towards openAL and yes he's right.
Maybe you will think about it and fix sth...
[quote]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); and we'd end up with people needing to install the oal dlls, which in typical fucknut amateur-hour stupidity are only provided as an EXE that requires Admin rights to install rather than as something you can just download and put in the Q3 dir, and that will NEVER be acceptable to me.
(Speaking of which, I actually tried to use ioq3 to run some tests, and discovered that I can't. They've lost the plot SO completely that you can now only get it via a *30MB* download and installer because of all the baggage. Broadband may be ubiquitous these days, but considering that cnq3 is ~550K and a single file that you just put where you want and it just WORKS, I shudder to think what the hell they're doing. Still, their project; their choice).
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).
I don't have to justify any decisions I make, so don't read it that way, but this was interesting enough (and I was in the mood :P) but still simple enough for me to use an example of the sort of calls we have to make and what goes into them behind the scenes that the mindless "I WANT X WHY YUO NOT DO IT?!" tardwhiners are completely oblivious to.
--
Rant Time:
The other thing that I found interesting was, as we all know, Creative bullied id into supporting oal in Q4 (and specifically, a bastardised version that ONLY worked on their hardware). Given the 30% performance hit of SW oal over a "good" implementation, it seems pretty likely that even the REALLY castrated (a laughable 24 channels) "generic" sound support in Q4 was a significant factor in why the game ran like ass (though I'm certainly not saying it was the ONLY reason, since AnthonyJ and others on the Q4MAX team including qrealka and myself got a ?40%? overall speedup just by replacing Ravencode with something competent, and that's not even counting the "vertexlight" hacks etc).
(edit: AJ says it's more like 55%).
Of course, both the "generic" AND "oal" sound systems in Q4 were (and still are) completely fucking broken, though in different ways.
This irritates me immensely, and puzzles me just as much. Creative have a huge monopoly in the "high end" sound card business, but seem determined to just do a Bad Job and waste developer time by forcing them to support both oal AND "something that actually works well", rather than simply make the "generic" oal FUNCTIONAL and a "real" sound card DESIRABLE through superior spatialisation and effects that you simply can't get in a software solution, and a nice performance bonus.
SURELY it's better for them to have oal truly become a standard for games and give people an incentive to buy their cards than to piss customers and developers off by trying to force them into it instead, resulting in far less oal support and thus far less reason to actually go out and drop $200 on some hardware. Maybe that way Q4 would have had one sound system and it would have actually WORKED, and players with high end sound cards would just have got, yknow, better sound. Maybe then the number of games would make it WORTH buying one of their cards, instead of being so short that they list ioq3 FIVE times just to try and pad it out.
But, they're Business People and I'm not, so apparently I'm wrong and it works well enough for them. It just seems a shame.[/quote]
