[openal] Ideas on an explicit context API

[Chris Robinson]

Hi.

OpenAL, like OpenGL, was designed on the concept of a current context. 
An application sets a context as current, and subsequent AL calls use 
that context implicitly when carrying out its operation. OpenAL differs 
in that it uses a global current context for the whole process, while 
OpenGL uses a current context for the calling thread only, and OpenGL 
doesn't allow the same context to be current on multiple threads at once.

I'm not sure what benefit OpenGL had with the concept of a current 
context (I suppose being able to remove one parameter from all calls, 
and the current context handle being a relatively easy lookup from the 
register pointing to TLB data), nor do I know how much OpenAL benefits 
since it uses a process-wide instead of thread-local context, but I know 
API-wise OpenGL's context handling has been regular sore spot with 
developers trying to use it within pre-designed systems.

With OpenAL, it's been an issue when trying to use it in a generic 
plugin system, such as a GStreamer sink or audio processor plugin where 
the app may be using OpenAL itself separately. In theory, 
ALC_EXT_thread_local_context can help if calls for a particular output 
are kept to its own thread, but this can't always be guaranteed. It's 
less than ideal in either case.

It's also been a constant bugbear with DSOAL, which converts DirectSound 
calls to OpenAL. DirectSound has no limitation on when or where you can 
make calls for different devices, it allows multiple devices to be used 
simultaneously across multiple threads. As it is, DSOAL uses a renamed 
OpenAL DLL to give it its own global state, so it can avoid stomping on 
whatever OpenAL contexts the app may be using. 
ALC_EXT_thread_local_context helps in as far as it allows multiple 
threads to handle different devices simultaneously, but introduces its 
own problems with making sure contexts are properly cleaned up, since 
they can't be unset from other threads they're current on when the 
device is closed.

So, I'd like to propose the idea of an explicit context API. This would 
allow the caller to use whatever context it wants wherever it wants, 
without worrying about some other code on another thread, or elsewhere 
on the current thread, using a different context. The general concept is 
that for every

alFoo(...) / alFooEXT(...)

function, there would be a matching

alFooExplicit(ALCcontext*, ...) / alFooExplicitEXT(ALCcontext*, ...)

function that does the same exact thing, just using the given context 
instead of the "current" one. Extensions would be implicitly included, 
so for an implementation that supports explicit contexts, any extension 
that defines new AL functions also gets an "explicit" variant (EAX, EFX, 
callback_buffer, etc). ALC functions don't need to be included since, 
aside from the device open functions and alcGetCurrentContext, they 
already take a context or device handle.

This would be a bit of an undertaking to implement since there are a lot 
of functions, and something would need to be set up so both implicit and 
explicit context calls could share the same underlying implementation 
without putting unnecessary burden on either path. So I'm putting this 
out there to get feedback on if it's something to pursue, or how 
precisely it could work, before putting effort into it.

Thanks,
Chris