Re: OpenAL device, buffer and context relationship

> One last question - What are these contexts, actually? Can you tell me where
> I can find more about that topic?


So at a higher level, there are different ways you can think about a context.

One way is that OpenAL draws a lot of patterns and metaphors from
OpenGL. In OpenGL, you might think of a context as an area you are
drawing to. You might imagine that you have a window you are drawing
to. That window happens to contain an OpenGL context which allows you
to draw OpenGL stuff to. But its possible to have multiple contexts.
For example, you may also be drawing stuff offscreen, perhaps to
precompute some images to later be displayed in your on-screen
window/context. Or perhaps you are planning to draw something and save
it to disk. But the idea is that you can have multiple contexts, each
of which is doing something completely different.

Another way to think about about the OpenAL context is if you casually
understand the three object types in OpenAL: listeners, sources, and
buffers. In this paradigm, the context is essentially the listener.
(There is only one listener per context.) When you move the listener
around in space, the attributes like position and orientation for that
listener are being saved in variables that belong to the context.

So let's construct an academic example where we have two OpenAL
contexts/listeners.

Imagine we have a little spaceship game like Asteroids. I designate
that your spaceship is the listener. So if a sound source explodes to
your right, you hear a sound come out on the right. Now, let's say we
have some kind of overlay-radar/map HUD that we can bring up. Pretend
that this map/radar looks sufficiently different from the normal game
that it won't make sense to continue playing sound from our existing
context. Perhaps the map/radar is in logarithmic scales so
everything's position is distorted compared to the game. Or perhaps
this map/radar is a mirror reflection so everything is flipped on the
wrong side. And maybe in map/radar mode, your spaceship is always
fixed dead-center while in Asteroids, you can move to the edges of the
screen.

So now in radar mode, we want a sound representation for everything to
handle these differences. We could just reuse our existing context and
plug in new values for everything. But an alternative approach would
be to create a new context just for the radar/map mode which has its
own positions for everything. This let's us keep our old context
untouched and pristine with all the original values so when we turn
off map/radar mode, we can just go back to that old context and not
have to reset everything.

Now that said, I don't think it is actually common practice to use
multiple contexts in OpenAL. I don't think most people think in this
way. And I have also noticed that functions like alcSuspendContext
don't work exactly the same way across all the platforms which may
cause complications in porting. And OpenAL doesn't really support
render-to-disk/memory options which would be the use case in the
OpenGL analogy I gave.

As for resources to read, there aren't a lot. The two official ones are:
The OpenAL Specification and Reference
The OpenAL Programmer's Guide
Both are free online.

Then I'm starting to promote my book, Beginning iPhone Games
Development which despite the name has a ton of OpenAL information,
but approached from a higher-level than the above two resources.
http://playcontrol.net/iphonegamebook
However, if you just care about contexts, I don't think you will get
much more than what's just been said here.

-Eric
_______________________________________________
Openal mailing list
[email protected]
http://opensource.creative.com/mailman/listinfo/openal