[Openal] Do any implementations support alcSuspendContext correctly?

[Chris Robinson]

On Wednesday 22 July 2009 7:40:20 pm Jason Daly wrote:
> Not sure about earlier versions, but the 1.8 version at least sets a
> mutex (critical section) there.  My guess is that this causes the mixing
> thread to block, so this isn't a no-op.

Actually, SuspendContext/ProcessContext are internal functions that hold a 
mutex for thread safety. The similarly-named exported ALC functions are 
unrelated.

I did experiment with making the ALC functions hold the mutex, but there's the 
issue that the ALC functions are not recursive, and it makes no mention of 
threading. For example, if alcSuspendContext is called twice, it still only 
takes one alcProcessContext call to resume, not two (the spec is pretty 
explicit about that). And if alcSuspendContext is called from one thread, 
alcProcessContext from another thread should still work. Or worse, two 
alcSuspendContext calls, one from each thread, is not disallowed by the spec.

I may be able to work something out with semaphores, but it will still rely on 
apps not keeping the context suspended for "long" periods of time ("long" in 
terms of sound card updates, which can be as few as a couple hundred samples 
per update).

> That said, I'm not sure how many implementations actually support
> multiple active contexts in a robust way.  I'd guess OpenAL-Soft and the
> Creative implementations would be OK.  Not sure about OSX.

OpenAL Soft can handle multiple contexts fine, although currently you can only 
get one context per device. To get two contexts, you need to open two devices 
and get one context from each (as long as the hardware/sound system supports 
it, you can open the same device twice, though).

The old software Windows code couldn't handle multiple devices/contexts 
properly, though. The callback for DSound output would only work with the 
current context. Funny enough, the WaveOut/MMSystem callbacks could handle 
multiple contexts (still one per device), but the mixing functions used the 
context-specific alGet* functions to get the source and listener properties. I 
don't know if this has been fixed or not, though.

> I know that Creative used Suspend/Process to do batch state changes on
> their hardware implementation.  It's more efficient and sounds cleaner
> to send several state changes at the same time, while the context is
> suspended, than it is to process them as you get them.  In a software
> implementation, this isn't as critical, so it's not all that surprising
> to see no-ops, I guess.

Personally, I wouldn't mind implementing alcSuspend/ProcessContext in a way 
that behaves like this, as there is some apparent value in making sure some 
changes happen at "the same time". If I block mixing updates while suspended, 
no mixing is done with the changed properties until processing resumes, at 
which point, the changes will be in effect simultaneously. As long as it's not 
suspended long, the sound card can catch up quickly. I just need to handle it 
with something more flexible than mutexes.

> The original sample implementation from Loki was radically different
> here.  IIRC, if you created a synchronous context, you had to constantly
> call alcProcessContext to handle the mixing and keep it updated.  I
> remember Chris being rather shocked at this part of the SI (this might
> have been what drove him to write OpenAL-Soft, actually :-) ).

Part of it, yeah. I wasn't sure if I could keep it working, or even if it was 
even working to begin with.