[Openal] Max number of sources (and legit id values) foreachOpenAL implementation

Thu Jul 23 01:35:30 PDT 2009

Hi All,

The original motivation for having the ALC_MONO_SOURCES and
ALC_STEREO_SOURCES hints was due to the fact that an OpenAL Source that can
be used to play buffers that could have anywhere between 1 and 8 (maybe
even more) channels of data.   For software mixers this is no big deal -
but for hardware devices that require one voice per channel (e.g Stereo
requires 2 voices) it is a big problem.   If you are running on a hardware
device with 128 voices then generating 128 sources and using them to play
128 mono buffers is OK - but you can't use them to play 128 Stereo buffers.

As it is quite likely that an OpenAL application (likely to be a game) will
play at least 1 stereo file (e.g. for music) the Creative OpenAL
implementations reserve one voice so that if you generate the maximum
number of sources, you can use them to play one stereo buffer and the rest
mono.   (You can see this by creating a context and querying the
ALC_STEREO_SOURCES attributes - it will be 1).

If you need to play more than one stereo voice at a time, then we recommend
that you use the ALC_STEREO_SOURCES context creation hint to tell AL how
many you will need to play *simultaneously*.   This enables OpenAL to
reserve the appropriate number of voices so that when you generate the
maximum number of sources, you are guaranteed to be able to play back your
requested number of Stereo buffers (and use the rest of the sources to play
mono buffers).  It is designed to make your life easier!

If you don't do that, then your only alternative is to check that all
operations involving attaching buffers to sources and play calls actually
succeed.  If they don't, then you need to free up some hardware voices -
this normally requires attaching a NULL buffer to a Source *not* just
stopping it.

Dan
Creative Labs (UK) Ltd.

Notice
The information in this message is confidential and may be legally
privileged.  It is intended solely for the addressee.  Access to this
message by anyone else is unauthorized.  If you are not the intended
recipient,  any disclosure,  copying or distribution of the message,  or
any action taken by you in reliance on it,  is prohibited and may be
unlawful.  If you have received this message in error,  please delete it
and contact the sender immediately.  Thank you.

Creative Labs UK Ltd company number 2658256 registered in England and Wales
at Belmont Road, Belmont Place, Maidenhead, Berkshire, SL6 6TB

             Jason Daly                                                    
             <jdaly at ist.ucf.ed                                             
             u>                                                         To 
             Sent by:                  Chris Robinson                      
             openal-bounces at op         <chris.kcat at gmail.com>              
             ensource.creative                                          cc 
             .com                      "openal at opensource.creative.com"    
                                       <openal at opensource.creative.com>    
                                                                   Subject 
             07/23/2009 03:13          Re: [Openal] Max number of sources  
             AM                        (and legit id values) foreachOpenAL 
                                       implementation                      

Chris Robinson wrote:
> According to the spec for alcGetIntegerv, "All tokens in table 6-2
(context
> creation) and table 6-4 (context query types) are valid for this call."
> There's a slight error there as table 6-1 is actually context creation,
and
> 6-2 is error conditions. The error condition enums don't make much sense
for
> the function, so table 6-1 is likely what it meant.
>
> The same table also has ALC_REFRESH and ALC_FREQUENCY (which would be
useful
> for apps to know) with ALC_MONO_SOURCES and ALC_STEREO_SOURCES.
>

I agree that it should be 6.1.  It also says that ALC_MONO_SOURCES and
ALC_STEREO_SOURCES are hints.  The original intent of these was to allow
the app to suggest to the AL how many stereo vs. mono sources it would
need, as hardware needs to know .  There's no guarantee that you'll get
what you request.

The spec doesn't explicitly say what you get when you query those,
either.  I wouldn't assume that you'd get anything more than the hint
value back, but I went ahead and did some digging.  There isn't much
about it (no one commented on it during the drafting process), but it
appears that the original intent was to allow you to query the minimum
number of mono and stereo buffers.

This is Garin's original post when he added these tokens to the spec:

http://opensource.creative.com/pipermail/openal-devel/2005-May/003068.html

I guess this is my long-winded way of saying you were right and I was
wrong  ;-)

> Though even if apps queried for the maximum number of sources, they would
need
> to force an artificial cap, all the same. There's nothing stopping an
> implementation from reporting 2^31-1 sources, but you wouldn't want an
app to
> try blindly allocating that many up front.
>

True enough.

> Apps need to treat sources as a limited resource for maximum
compatibility,
> anyway. Testing and developing on a system with unlimited sources, and
then
> having it run on hardware with only 64 voices, would be a rather big
problem.
> Sources need to be managed so they can be reused/stolen/etc, on systems
from
> as few as 16 voices, up to however many. Fewer maximum voices will of
course
> degrade quality, but when you get up to 256 simultaneous sources, a good
> manager should be able to make that virtually imperceptible, I think.
>

Agreed (in most cases, at least).

--"J"

_______________________________________________
Openal mailing list
Openal at opensource.creative.com
http://opensource.creative.com/mailman/listinfo/openal

ForwardSourceID:NT0006E0B2