[openal] Ideas on an explicit context API

[Chris Robinson]

On 4/24/23 04:56, hypatia.sva at posteo.eu wrote:
> Hello,
> 
> is this kind of what you wanted?
> 
> https://github.com/hypatia-of-sva/alad/blob/main/openal-explicit-polyfill.h
> 
> It's currently no better in terms of performance, as its temporarily 
> swapping contexts, but I would be interested if that is kind of the 
> semantics you are interested in or if it's different.

That's the general idea, yeah. Looking at that, it does being up the 
question of the buffer functions taking an ALCdevice instead of 
ALCcontext. I'm not sure about doing that. Technically it could work 
since the spec says buffers are part of the device the context belongs 
to, and they can be accessed with any context on the same device, but it 
could introduce ambiguity with other objects introduced in extensions, 
like filters and effects from EFX.

I don't think the EFX spec says anything about where they're stored, but 
Filter and Effect objects essentially just hold configuration parameters 
that are later applied to a source or auxiliary effect slot. It makes 
sense for them to be part of the device and can be shared between 
contexts like buffers, which is how OpenAL Soft implements it, while 
auxiliary effect slots are part of the context like sources. But the EFX 
docs don't seem to say what they're part of. Trying to guess and be 
wrong with whether certain object types should take a ALCcontext or 
ALCdevice, or trying to change it in the future, could be a problem.

If others feel it's fine, I won't push it as long as it's clear what 
should take a device handle instead of a context handle. Otherwise, I 
think it's best to stick with ALCcontext* for all AL functions regardless.

> I also added the possibility of having multiple listeners per context. I 
> don't know if thats truely necessary for anything, but since it's 
> trivial to add I thought it might as well be there to differentiate 
> which function
> changes which state information.

The problem I see with that is it would cause sources to have different 
state on the same "context". A non-0 velocity on any listener or a 
source would result in different relative movement to a source, causing 
a different pitch on different listeners and the source having different 
playback offsets on each when playing. It would effectively be two 
different sources, with some shared caller state.