TL;DR: OpenAL is badly designed and badly documented.
The long story:
Creative employees themselves advise to use OpenAL Soft
instead of the implementation provided by Creative (I however haven't used OpenAL Soft yet and therefore can't currently vouch for it). Apparently it is also faster.
You can read about that suggestion in their mailing list here: http://openal.996291.n3.nabble.com/what-s-going-on-with-connect-creativelabs-com-td5546.html
ALC_STEREO_SOURCES
as well as ALC_MONO_SOURCES
are indeed hints, however they should also be queriable using alcGetIntegerv
. You can also read about that in their mailing list: http://openal.996291.n3.nabble.com/Max-number-of-sources-and-legit-id-values-for-each-OpenAL-implementation-td3200.html
From this description it's not clear, if ALC_STEREO_SOURCES indicates
max sources that can be created via alGenSources, or maximum number of
simultaneously playing sources.
From what I gathered, nobody knows. It depends on the implementation and the documentation is very unclear about it (and many other things) as you already noticed.
There's another problem I read about:
alcGetIntegerv
might for example tell you you can play/have 32 sources. Depending on the OpenAL implementation however, that number can be shared across processes. Therefore other processes subtract from that number without you knowing about it. At runtime that will result in an OpenAL error when you try to create or play a source while you're still within your limit of 32 sources.
Personally I'd write a source manager that recycles sources and allocates a new source only if there is no unused source left.