[Openal] No voices?
garinh at cheesetoast.net
Fri Oct 21 16:30:56 PDT 2005
> When AL was less well specified and still in significant flux,
> Creative was also working on their semi-fork and (a Creative
> bod can probably correct me if it's at all interesting)
> either didn't understand the point of infinite sources or
> (more likely) didn't want the complexity of the dynamic voice
> management that would be necessary for their hardware
> implementation - so the spec got retrofixed.
It probably worked much this way, but not exactly. Loki got their
software implementation going first, and we got going at Creative on
our accelerated versions (the DS3D version qualifies, as it's bound
by the limits of the hardware "voices" in terms of how much audio you
can actually mix and output). We limited the number of sources to
what the hardware can handle for very good reasons. If you do some
sources in hardware and some in software, you end up looking at
solutions like these:
1) Have a situation where "some sources are more equal than others."
That is, sources which are bound to hardware voices could have 7-
point interpolation (scaling to the systems of the day), EAX effects,
and be positioned anywhere on your 5.1 speaker setup, but software
sources would have linear interpolation, no EAX, and be in stereo only.
Such a situation could of course be mitigated, but such methods
themselves were undesirable:
a) by establishing a voice management scheme in OpenAL (dismissed
b) having various classes of source with the ability to enumerate
and assign capabilities -- just adds a lot of complexity to the API,
which went against what we were collectively trying to accomplish
c) by re-implementing all our hardware features in software, so
that the first sources would be in hardware, and all remaining
sources in software -- this would cause an interesting discontinuity
and a lot of testing and bugfixing (remember, the machines in 2000
were a lot slower than modern machines); we'd get people coming back
to us saying, "Well, this OpenAL stuff is great, but on my Live card
my game runs great with 30 sources, but if I add more then my frame
rate goes down by 2% for every additional source. Why's that?"
2) Implement a voice management scheme in core OpenAL so that the
API pretends to support an infinite number of sources, but doesn't
really do so.
We just didn't want to do this -- the whole point of separating
"sources" from "buffers" was to avoid voice management at OpenAL's
Realistically, the situation for "infinite" source software solutions
and hardware isn't really all that different, at least for gaming
applications. Unless you want your app to consume a huge amount of
CPU resources (anything over 5% in a game is not going to be seen as
acceptable, and with accelerated implementations the CPU hit should
be well under 1%), you're not likely to stray too far beyond the
limits imposed by the hardware implementations (now 127 sources in a
typical scenario on an X-Fi board). For instance, all the Loki
products ever shipped had a maximum source count well within the
bounds of what a Live card (the best hardware solution of the day)
could handle in hardware, despite the fact that their underlying
OpenAL implementation wasn't limited.
More information about the Openal