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

[Jason Daly]

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"