[Openal] No voices?

[Garin Hiebert]

> 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  
below)
   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  
level.

-----

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.

Garin