3DsoundSurge Special Feature
Aureal vs Qsound - The Great
Debate
Qsound:
Scott Willing
Aureal: Toni
Shneider
Date Started: June
22, 1998 Date Ended: July 8, 1998
Scott Throws
His Opinion
If I may, I'd like to address the
comments from Toni Schneider of Aureal.
--------
Toni says that Aureal's goal with respect to API's is to support industry standards
as well as their own API. Obviously, this is from the standpoint of their hardware
products.
I'm actually very pleased that Toni made this statement, as it may help to clear up
something for consumers and even the trade press: a game written to pure DirectSound3D (or
indeed using either of QSound's SDK's) will work just fine with Aureal sound cards.
Specifically, the current A3D API is not needed to support current A3D hardware. If the
developer has done a good job of DS3D programming, such as handling resource management,
using the A3D 1.x API really adds absolutely no additional value that I am aware of. I
know I can trust Toni to correct me on this if I'm wrong. <g>
While we're on the subject, since it is
Aureal's stated policy to support industry standards, I presume that Aureal API's and
hardware will now support the Voice Manager property set for universal resource
management?
Toni says that QSound "seems to have a
problem" with A3D 2.0.
Let me clarify.
First of all, we fully accept that Aureal
has every right to bring forth technologies and support them through their own API's. Of
course! If it is not practical to provide support for something like wavetracing through
the industry standard "property set" mechanism, we can understand this too. No
problem, no issue. What I suggested was that, if practical, it would be a good thing
for Aureal to support a generalized reverb interface through a (soon to be) industry
standard API such as EAX. Toni has indicated that indeed Aureal is at least prepared to
consider this, and we welcome that statement. It's very progressive. So, again, no
problem.
Clearly, some developers may choose to
support the non-standard features of A3D 2.0 in addition to using universal DS3D
code. Again, we wouldn't dream of trying to discourage this. That's both their
right and their business!
What we take issue with is that, from the
developer (not hardware) perspective, Aureal has consistently employed a strategy of
discouraging ISV's from supporting competing hardware. One can only assume that the goal
is to create the impression of a defacto standard. The (ongoing) surveys that we're doing
clearly indicate that most developers know better than to adopt an exclusive
hardware support approach for current and future projects.
Some early 3D titles came out with
exclusive support for A3D. The reasons are pretty simple: Aureal had the only hardware in
the market, DX3 didn't support generalized hardware acceleration, and Aureal actually
wrote the 3D audio code--at no charge--for some developers who hadn't the time or
inclination to deal with it!
That was very shrewd marketing, but the
world has changed--frankly, faster than even I expected. Anyone can call/mail these
developers and ask them the same question I have, i.e., "Are you planning general
DS3D hardware support?" You certainly don't have to take my word for it. I'd rather
you didn't, in fact.
Toni talks about installed base of a
million units, but this invites the question: what does this have to do with A3D 2.0?
Those cards can be supported without the A3D API, so the point is moot.
Furthermore, one manufacturer _alone_ has
already shipped seven times more PCI audio chips than Aureal. By the end of the year the
market will be full of positional 3D audio cards powered by algorithms from a least a
half-dozen 3D vendors. All indications are that the vast majority will not be A3D cards.
For this simple reason it's unwise for developers to support_any_vendor's audio hardware
exclusively--and they know this all too well.
QSound's developer policy is at the
opposite end of the spectrum from that of Aureal. We have expended--and will continue to
expend--considerable effort to help developers support all 3D hardware effectively and
easily--including Aureal's own hardware.
Heck, if the 2.0 API was public, we might even consider support for\ that, too--if we
thought it was going to get sufficient market share.
QSound does not seek exclusive support for
our hardware. We would certainly not write a developer's sound code for them such that it
only supported our hardware--that's hardly what I'd call legitimate developer
"endorsement." Who wouldn't accept a freebie?
(Come to think of it, maybe developers
should fire all of their audio programmers and let Aureal do all their sound code.) So
QSound does not have a "problem" with A3D 2.0 per se. We have a different
corporate philosophy, that's all. Let's get nitty-gritty on the features of A3D 2.0. Toni
states that 2.0 offers "...new features not available anywhere else." The first
example is universal host emulation. The primary value of any "emulation" mode
is that something logical and useful happens to the audio when all these fancy 3D commands
land on a non-3D equipped system. The result should be fast, effective, have
no negative side effects and cause the developer no coding grief.
Contrary to Toni's statement, Aureal isn't
the only company providing host emulation. In fact, they're late to the party; this
was never a feature of A3D 1.x. Microsoft DS3D offers universal host emulation. It
was part of the design from the beginning. I'm not saying it's great (on the contrary) but
it's there, and over time I have no doubt that it will improve.
QSound's QMixer offers not simply host
"emulation" but full-on 3D for speakers and headphones that runs performance
circles around some hardware "accelerators." Not free, perhaps, but not
expensive either, and a far more effective host solution than a half-hearted
"3D-ish" algorithm. Our licensees obviously consider it worthwhile.
QSound's QMDX SDK also offers host
emulation, and like DS3D and A3D, it is completely free to developers. On non-accelerated
hardware, QMDX mixes to stereo at very low CPU overhead, with panning, range-related
volume scaling and Doppler shifting automatically derived from the 3D positional
information. The developer needs to write not one additional line of code.
Why stereo? It would be child's play for us
to provide a high-efficiency version of a basic headphone algorithm in QMDX. (This is what
DS3D and A2D supply.) However, in our view this isn't a feature, it's a drawback.
Headphone processing--even a basic
algorithm--creates unacceptable phase pressure when monitored over loudspeakers, yet
achieves no extra-stereo placement at all. Even on headphones, such a basic
algorithm doesn't provide a great deal of benefit. Bottom line: the cycles consumed
for low-grade "3D-ish" emulation can't be justified by the end result.
High-quality stereo mixing (again, with
panning, range and Doppler) can be achieved with a minimum CPU hit, and doesn't have
negative artifacts for either speaker or headphone listening. Better idea.
Advanced resource management is the next
feature that Toni claims is exclusive to A3D 2.0. I am baffled by this statement, as again
both QMDX and QMixer offer incredibly versatile high-level resourc management that can be
as automatic or as finely controlled as the developer wishes. These SDK's are publicly
available on our web site right now (http://www.qsound.com/gamedev)
if anyone needs proof. To the best of my knowledge, A3D 2.0 is not
available--publicly or
otherwise--at this point in time. (Again, please correct me if I'm out to lunch here.)
So now we get to the only truly unique
feature of 2.0: wavetracing.
First of all, it's important to understand
that wavetracing is not exactly rocket science. For marketing purposes it sounds pretty
whizzy, but let's put this in perspective: any college student can do the math. If
developers were really jumping up and down screaming for wavetracing, I expect every
vendor of 3D technology could provide it without breaking a sweat.
For the purpose of this discussion let's
set that issue aside and simply accept that wavetracing is a scientifically
legitimate method of creating environmental audio effects. It is! Now the important
questions become:
- How much value does it add to real game play
(ignoring all other issues)? Especially, how much better is it than
"simple" reverb? (More on that in a minute.).
- How easy is it for developers to use?
- What will it cost in terms of latency and
CPU overhead?
- What will it cost in terms of the price of
the sound card?
- Will the installed base be significant
enough to warrant the development effort required to support it?
1. Game play value
I'd like to provide some perspective before
I state a personal opinion. I'm not trying to represent myself as an "expert"
(I'm suspicious of people who do) but I want the reader to understand my perspective.
I've been involved with audio for more years than I care to admit, and 3D audio for
the better part of a decade. When evaluating a
given audio technology, the first thing I'm interested in is how it actually sounds in the
environment for which it is intended. Next, I consider what it costs and how easy it is to
use, and thus form an opinion of its overall value. I do not make decisions based on
what a technology might sound likewith my chin nailed to a post in an anechoic chamber.
This has nothing to do with real life. Neither do I make decisions based on the theory
underlying the technology. I don't read white papers while I'm shooting aliens or
listening to tunes in order to figure out what I should be hearing. Does it work?
How much does it cost? What else could possibly matter? So here's a personal
opinion:
With respect to rendering reverberation in
a closed virtual space, and especially in the context of game play, wavetracing will most
often be virtually indistinguishable from a decent generalized reverberation algorithm.
I leave it to others to decide for themselves if they agree or not, and I sincerely
hope that they do so by listening. The simple truth in this market: What ten hardcore game
players think about what they hear is far more important than the beliefs of every
3D audio vendor and theorist put together, including Toni and I both.
How easy and convenient to dismiss
alternatives to wavetracing as "simple reverb." This dismissal relies on a
low level of general audio knowledge amongst consumers and computer press people who are
struggling to educate themselves in what is--for them--a new field.
For the benefit of those who are new to
these principles (long understood in the industry): any half-decent reverberation
algorithm does indeed include reflections which are created according to the specified
size and other acoustic properties of the space. This isn't equivalent to wavetracing, but
it is much more closely related than we would be led to believe by Aureal.
Now, occlusion (a $50 word for
"obstruction") effects are far more obvious (i.e. audible) and far more
important to providing the game player with useful feedback. That is, the fact that
the enemy is outside of the room far outweighs the value of the 12.6ms delayed
reflection of his grunt that bounces off a wall somewhere. The latter is unlikely to
be noticed!
Finally, wavetracing isn't the only way to
handle occlusions. It is only the most compute-intensive method.
2. How easy is it to use?
Since Aureal hasn't revealed details of
their API in public, we can only make some assumptions. One is that geometry
information must be passed to the sound engine somehow. That's potentially a lot of
work for a limited return on development effort.
Getting back to our survey, developer
reactions range from "I will never use that" to "sounds very cool." In
between is the vast majority, who haven't come to any conclusions because they have
nothing to evaluate.
Obviously it is premature to assess how
hard or easy wavetracing maybe to use. At this point it's mostly vapourware. However, it
is not premature to conclude that ease of use is going to be a major issue for developers;
it always is.
3. Latency and Overhead
Again, these are vitally important issues
for gaming--even more so than ease of use. Will the interpretation layer (where all the
path calculation happens) live at the driver level on the host? If so, latency and CPU
overhead might well be a problem. And again, we have zip to go on, so we can only suggest
that people take nothing for granted and dust off VTune when the chance arises.
4. Sound card cost
If the (substantial!) additional
calculation and signal processing requirements for wavetracing are undertaken in whole or
in part on the sound card hardware, this won't come for free. More memory,
more DSP bandwidth, more program space--all these things require more hardware to
support.
Wavetracing may well push the hardware into
the high-cost/low-volumemarket segment. Or, to avoid this, additional processing may be
pushed back onto the host, which brings us back to point number 3.Either way, we're
talking about a relatively high-cost technology.
5. Installed base
The developer will very soon have the
following choices with respect to environmental audio:
a) Forget it!
b) Preprocess it.
c) Use a straightforward, universal property set API (EAX).
d) Support both the EAX property set and A3D 2.0.
e) Support A3D 2.0 exclusively.
Toni points out that EAX doesn't exist in the market. OK, but none of this stuff exists in
the market! I don't think anyone would deny that 3D vendors and hardware OEM's will
support a standard like EAX once it's established. That will be where the big numbers will
be.
Toni mentions all the API's that the use of
EAX requires. Well, it turns out that lots of developers (many more than I expected) have
already wrestled DS3D to the ground and have it under control, thanks very much. It's
challenging, but you only have to solve the problems once and then you have a library you
can reuse for other titles. To these folks I say: congratulations. Your effort will serve
you well.
But it doesn't have to be so painful. For
those who haven't climbed the mountain yet, QMDX and QMixer are two SDK's that support all
DS3D accelerator hardware, resource management, non-accelerated systems, and many more
fundamentally useful audio features under a single API. As soon as EAX, or some
modification thereof, is established as a standard, they will both support that too, so
"EAX = nightmare" is hardly a valid equation in my math book.
We're back to the issue of universality.
The smart money is on supporting universal standards, and I suspect that even those who
use A3D 2.0's wavetracing will also support the broad-market solution. They will have
everything to gain and nothing to lose.
As much as those of us in the sound
business would like it to be otherwise, we have to put things in perspective.
Environmental audio is only an enhancement to 3D audio, which is only an enhancement to
stereo audio, and audio, however unfairly, is a weak sister to graphics in entertainment
software. At the end of the day, like hi-fi fanatics debating the merits of oxygen-free
cable, we're talking about things that are only a small component of the overall picture.
Due to considerations of real-time
performance and development effort, when it comes to the crunch, the first thing to get
cut will be environmental audio. (That's nearly a direct quote from an audio programmer
working for possibly the most sound-hip developer on the planet.)
IMHO, wavetracing is in fact
supplier-driven, not market-driven. That is, there is no evidence that a large
number of developers have been dying to get their hands on this stuff. On the
contrary, many of them are just coming to grips with DS3D, as some of the comments on the
3D Sound Surge web site clearly show.
QSound is focused on making game
development easier, not more complicated. The reason is simple: content rules! All the
groovy bells and whistles won't save a game that sucks, so the tools had better facilitate
the creation process rather than complicating it.
In summary:
QSound does not have a "problem"
with A3D 2.0 per se, although Aureal may.
Wavetracing is the only unique feature in
2.0, and its value compared to broader alternatives is open to an awful lot of unanswered
questions.
QSound believes in supporting and
encouraging open 3D audio standards wherever possible, and in providing practical,
effective, broadly applicable solutions to real-world programming needs.
We think that competition between 3D
vendors should happen on the retail shelf, not in developer boardrooms. We're not afraid
to compete head-on in the street, where performance/cost ratio is the only thing
that matters. We think developers should be as free from unnecessary hassle as
possible so they can get on with the task of writing kick-ass games.
Any questions?
Best regards,
Scott Willing
QSL
|
All content, design and work is ©
2001 - 3D Sound Surge Please respect the copyrights of the articles and writers herein. All copyrights are enforced by 3DSS.