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

[Jason Daly]

Chris Robinson wrote:
> On Tuesday 21 July 2009 1:35:34 am E. Wing wrote:
>   
>> Hi, I am writing some stuff about OpenAL and I would like to get my
>> facts straight. Can people verify my information about the maximum
>> number of sources?
>>
>> Creative Labs:
>> I recall seeing this in an old mailing list thread.
>> Generic Software: 256
>> Generic Hardware: 16-64
>>     
>
> Note that the Generic Hardware device depends on the hardware. It uses 
> DirectSound3D, so if that reports >64 (or even >256) voices, that's how many 
> you can get.
>
> AFAIK, you can get the maximum number of sources by:
>
> ALCint nummono, numstereo;
> alcGetIntegerv(device, ALC_MONO_SOURCES, &nummono);
> alcGetIntegerv(device, ALC_STEREO_SOURCES, &numstereo);
>
> printf("Max sources: %d\n", nummono+numstereo);
>   

That query is not in the spec.  It might have been added as an extension 
(you'd probably know that better than me), but it's not a standard 
query.  The only standard way to get the number of available sources is 
to generate them until you get an error. 

This might be another good candidate for a 1.2 spec, although I don't 
know the hardware implications of it.  I think DS3D had a query for 
this, though, so it shouldn't be a problem...


> OpenAL Soft lets the user pick the maximum number of sources in its config 
> file, in case of apps maxing out the number of playing sources on slower 
> systems that have trouble keeping up with the mixing. By default it provides 
> 256.. I could've made it virtually unlimited (ie. up to 2 billion, depending 
> on available memory), but I cautioned against that in case there were apps 
> that allocate as many sources as the system will provide.
>   

Since there's no standard query for available sources, most apps will do 
this, although they also typically have their own artificial cap (give 
me as many sources as you can, up to 256).  The old SI didn't have an 
arbitrary limit, so an artificial cap was necessary.

--"J"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://opensource.creative.com/pipermail/openal/attachments/20090722/33340611/attachment.html