[Openal] Do any implementations support alcSuspendContext correctly?

[Jason Daly]

E. Wing wrote:
> I am looking at the Mac OS X implementation of alcSuspendContext
> (partly because I am trying to figure out the best way to handle a
> phone call interruption on iPhone).
>
> I discovered that it is a no-op. I found the following comment in the code:
>
> 	// This code breaks Doom 3 [4554491] - The 1.0 implementation was a no op.
> 	// Since alcProcessContext()/alcSuspendContext() are also no ops on
> sound c ards with OpenAL imps, this should be ok
>
> I was rather startled at the claim that nobody implemented this.
>
> I skimmed through the OpenAL Soft code, and it looks like a no-op there too.
>   

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.


> On iPhone, it seems to behave as a no-op. But interestingly, if I make
> the current context NULL, the behavior acts like a SuspendContext,
> where the audio state pauses. So if I was in the middle of a sound,
> when I resume the context after some arbitrary amount of time, the
> sound resumes from where it lefts off.
>   

Interesting.  That's not the intended behavior.  Contexts that aren't 
current should still continue to be processed.


> But thinking about this, this is really not the behavior I want from
> switching contexts. I've been toying with a multiple view design
> pattern for Mac desktop applications where I have multiple OpenGL
> views (each with a separate context). I want to mirror that with each
> having its own OpenAL context to go with each view. When the user
> changes the active view focus, I want to switch OpenAL contexts to the
> new active view. But if a sound was in the middle of playing on the
> context that is being swapped out, I don't necessarily want the
> context suspended. (The audio is likely coordinated with the visuals
> and the visuals keep moving as they may be visualizing live data.)
>   

In my understanding, that's how it's supposed to work.  You might get 
into resource contention if you have too much going on, but basically, 
what you laid out is the right idea.

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.


> Any how, I am wondering, do any implementations out there support
> alcSuspendContext correctly? And do all the implementations suspend
> the context if you swap out the current context?
>   

There has been a lot of confusion on alSuspend/ProcessContext over the 
years.  The 1.0 spec wasn't very clear on it, and 1.1 wasn't much 
better.  As a result, it seems that the implementations each did 
whatever they felt was most appropriate for their platform, even though 
this may have led to inconsistent behavior.

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.

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 :-) ).

It sounds like OSX may have taken even a different tack here (at least 
on the iPhone).

Since we seem to be talking about 1.2 spec issues today, maybe this is 
another one to add to the list.


--"J"