From: "Michael Vance" <michael@xxxxxxxxxxxxxxxxxxxx>
Sent: Thursday, December 23, 2004 11:55 PM
isn't actually playing, then what hardware resources is it taking up? Surely it
can't have much
overhead. On the other hand, if a piece of hardware can only play a certain number of
"voices" at
a time, then that's fine. It's up to the programmer to shut off sounds that
have low priority if
they want to play another one. This would mean a better match between a game engine
"source" and
an API
Well, you'll have to have some robust API for that limit to be discoverable.
Right now, that
interface is "create sources until that fails" which seems a bit awkward to me.
And the error
reporting mechanism shouldn't be a method of introspection, really.
Agreed. Perhaps some get-able integer property: AL_MAX_SOURCES for example.
Good idea for 1.1
anyway, regardless of any other changes discussed here? Although if more than
one AL app was open at
once, wouldn't this number be reduced for one program as the hardware was taken
up by another app?
allowing more sources than they currently do (virtually unlimited?) In fact,
since cards usually
allow 32 or 64 voices these days, voice management may not even be necessary
for programmers;
more than that number of simultaneous voices would likely sound bad anyway!
This is of course a very foolish way to think :), software will always consume
as much hardware
power as it can. You can easily run out of hardware voices, especially given
that sound hardware
processing isn't necessarily as discrete as "you can have 32 of these". If you
have effects, like
reverb, applied to certain sounds (and stereo sounds take two voices, remember)
you can be using
more DSP than if they were just straight mixing, which could limit the number
of hardware voices
the hardware can operate on within a sound frame to some non-32 or non-64
value. And also make it
variable! <nda> We could certainly do this on the GameCube if we pushed it hard
enough </nda>.
Oh yeah, I wasn't meaning to imply it would never be necessary to put some
management in. Just that
for simple apps with many logical sources but a low number playing
simultaneously, this would move
some common work from the app programmer's task into the API. Obviously a
pro-level app will need
something more sophisticated.
I hadn't thought about adding effects though, or multi-channel sounds. Does
this affect the current
implementation though? What happens if I make as many sources as I'm allowed on
say an Audigy, then
whack lots of EAX effects on each one and start them all playing at once?
Wouldn't the idea of
"number of sources in existance" as the hardware resource fall down here as
well? Doesn't your point
still apply only to *playing* sounds, which is what I'm stabbing at?
Andrew
Oh, and happy new year everyone - let's make it a productive one for OpenAL!
|
