[Openal-devel] Atomicity defect with listener AL_POSITION and AL_ORIENTATION

[jmt at atc.creative.com]

Alexandre,
I fully understand your concern for the use of the GL coordinates to drive
the audio. However, I believe this would best be handled by an ALUT type
library.
Also, don't worry about simultaneous property updates: you can the
Suspend/Process Context feature of OpenAL to do this:
1/ suspend the context with alcSuspendContext()
2/ change all the properties you need to update: no change will heard
3/ process the context with alcProcessContext(): all properties are now
updated in the renderer.
      Jean-Michel.

-------- Notice --------
The information in this message is confidential and may be legally
privileged.  It is intended solely for the addressee.  Access to this
message by anyone else is unauthorized.  If you are not the intended
recipient, any disclosure, copying or distribution of the message, or any
action taken by you in reliance on it, is prohibited and may be unlawful.
If you have received this message in error, please delete it and contact
the sender immediately. Thank you.


openal-devel-admin at opensource.creative.com wrote on 04/20/2005 01:20:59 PM:

> I see a serious problem with using AL_POSITION and AL_ORIENTATION.
> (This just occured to me while I was thinking about matrices.)
>
> The fact that AL_POSITION and AL_ORIENTATION can't be updated together
> atomically means you can get some serious unwanted audio artifacts if
> the listener position and orientation both jump suddenly (such as if
> you go through a teleporter).  For example, when going through a
> teleporter, you could have a sound momentarily jump from your left
> speaker to your right speaker after you update AL_POSITION, and then
> jump back to your left speaker after you update AL_ORIENTATION (so you
> really would have liked AL_POSITION and AL_ORIENTATION to update
> together atomically).
>
> I'd like to advocate replacing AL_POSITION and AL_ORIENTATION with a
> single matrix.  This would fix the problem, since a matrix can be
> updated atomically.
>
> Below are three more reasons why I think a matrix would be better than
> listener AL_POSITION and AL_ORIENTATION (to transform the AL_POSITION
> of a source to ear coordinates).
>
> 1. A matrix would be faster and more powerful than using listener
> AL_POSITION and AL_ORIENTATION.
>
> 2. A transformation matrix (the GL_MODELVIEW matrix) is always readily
> available from an OpenGL application, but listener position and
> orientation is not always easily obtainable from an OpenGL application.
>
> 3. You probably want OpenAL ear coordinates to match OpenGL eye
> coordinates and OpenAL object coordinates to match OpenGL object
> coordinates.  However, currently this is not always possible.  The
> GL_MODELVIEW matrix is used to transform from OpenGL object coordinates
> to OpenGL eye coordinates.  AL_POSITION and AL_ORIENTATION are used to
> transform from OpenAL object coordinates to OpenAL ear coordinates.
> However, AL_POSITION and AL_ORIENTATION aren't powerful enough to match
> the flexibility of OpenGL's GL_MODELVIEW matrix.
>
> _______________________________________________
> openal-devel mailing list
> openal-devel at opensource.creative.com
> http://opensource.creative.com/mailman/listinfo/openal-devel

> ForwardSourceID:NT00017302