[Openal-devel] alcSuspendContext()

[Daniel PEACOCK]

Hi,

> >> On Monday 18 February 2008 03:52:01 am Richard Furse wrote:
> >>> Okay. Batching-up of state changes seems sensible/necessary to me in
the
> >>> asynchronous scenario, in the same way that transactions provide
> >>> consistency in SQL databases. If a source is initially at <0,0,0> and
a
> >>> listener at <10,0,0>, and the source is moved to <9,0,0> and the
> >>> listener to <19,0,0> in one "batch", then I'd expect OpenAL not to
> >>> glitch. Without suspension, there's a risk that a block of audio is
> >>> rendered half way through the state changes, i.e. with the source at
> >>> <9,0,0> and listener at <10,0,0> - which would be bad.

That is a possibility - hopefully it wouldn't happen very often though.
The hardware renderers do interpolation of levels so relatively large jumps
shouldn't cause clicks or pops - but software solutions (including
host-based soundcards) may not do this.

> I think (I hope! since that's what I'm using...) that using listener
> relative sources with a non-moving listener avoids this issue.

You could solve the problem by leaving the Listener's parameter at their
defaults, and providing all the Source parameters in their transformed
state (e.g rotated and translated with respect to the world's camera /
player character's position and orientation).

> In my FPS game I noticed that
> sometimes sounds that were played locally (i.e.
> listener position == source position) were
> sporadicly -- but definitely noticeable -- lagging
> behind for a fraction of a second.

Are you enabling SOURCE_RELATIVE mode on the Source?  This should prevent
that type of artifact.

> > I would very much like OpenGL-like alFlush() and alFinish()
functionality!

I'm not familar with those OpenGL functions - but I am in favour of adding
something to OpenAL that allows batching parameter updates together in a
defined manner.  It is NOT optimal to calculate every Source's levels in
response to a Listener Set Position call, and then immediately re-calculate
each Source's level again because the application calls Set Position on
each Source.  This is a very scenario in games.

Using alcSuspendContext & alcProcessContext to do batched updates has
caused some problems.   Not the least is that it is *very* tricky to get
this right because it is necessary to know about order or operations as
well as all the state and parameter changes.  e.g. Source 1 has Buffer 1
attached, app. calls SuspendContext, unqueues Buffer 1 from Source 1, fills
Buffer 1 with new data, attaches Buffer 1 to Source 2 and plays Source 2.
If this is done in the wrong order then either you will get failures and /
or end up with the wrong audio playing on Source 2.  Similar problems exist
in EFX 1.0 concerning Aux Effect and Source Effect Send updating when you
can end up with a Source momentarily feeding the wrong effect (which if it
is has a delay will be noticeable).

> Does anyone know if "real" games out there use alcSuspendContext()
> and expect it to work?

It has been used in "real" commercial games.  Under certain circumstances,
and on certain soundcards it can work well.  However, it can also cause
problems.  It really depends upon what you calls you make between Suspend
and Process.  IMHO I would recommend not using these calls.

Dan
Creative Labs.