[Openal-devel] alcSuspendContext()

[Chris Robinson]

On Saturday 16 February 2008 06:55:10 pm Garin Hiebert wrote:
> Actually using the call to suspend mixing would always result in
> glitching (assuming audio is playing), which seems pretty useless to me
> (maybe some implementation did that at one time, but I hope that isn't
> currently the case).

Reading the annotations, it certainly seems this was the case. An synchronous 
context was designed for systems that didn't have feasible async mixing, or 
where such would be undesirable, and alcProcessContext was there to poll a 
context for mixing, while alcSuspendContext was to stop the output stream to 
keep it from underrunning. In an async context it serves a slightly different 
purpose.. alcSuspendContext behaves more or less the same (stops the output 
stream), while alcProcessContext restarts output and is just a no-op when 
called on a running stream.

Relavent notes from http://www.openal.org/oalspecs-annote/x1489.html:

"Unfortunately, the exact semantics of alcProcessContext is not independend of 
the implementation. Ideally it should be completely transparent to the 
application whether the sound driver is threaded or synced. Unfortunately a 
synced context has to have its execution initiated by the application, which 
requires calls of alcProcessContext timed in accordance to the drivers 
mixahead, or the rendering buffer will underflow."

"For a threaded implementation, alcSuspendContext is necessary to ensure a 
context is not processed. For a synchronous implementation, omitting 
alcProcessContext calls will ultimately have the same effect, but will also 
generate rendering buffer underflow errors. Again, the application coder that 
requests a synchronous context using ALC_SYNC has to make sure that 
alcSuspendContext is used accordingly."