Chris Robinson chris.kcat at gmail.com
Wed Sep 30 17:52:37 EDT 2015


I have a question about the source's AL_ORIENTATION property, introduced 
with the AL_EXT_BFORMAT extension. The property defines an orientation 
for the source, so that it can rotate a B-Format sound field by defining 
the front+top of the source. This makes enough sense since the existing 
AL_DIRECTION property isn't enough to define an orientation.

However, it does create a slight issue in that a source now has two ways 
to define a direction, which apps need to account for. A mono source 
defining the front of a cone needs to use AL_DIRECTION, while a B-Format 
source defining the front+top of a sound field needs to use 
AL_ORIENTATION, even though they're both conceptually defining the how 
the source is facing. So I'm curious if the source's AL_ORIENTATION 
property should, or is supposed to, supersede the AL_DIRECTION property 
such that the orientation also defines the front of a mono source's 
cone, and AL_DIRECTION is effectively deprecated.

Unfortunately, it's not really possible for the orientation's "at" 
vector to alias the direction vector, since they have different defaults 
(orientation default is {0,0,-1, 0,1,0}, while direction default is 
{0,0,0}). However, assuming it won't create a compatibility problem, I 
think one option is to make setting AL_ORIENTATION also modify 
AL_DIRECTION, while still leaving them as separate properties. So for 

alSourcefv(source, AL_DIRECTION, {0, 0, 0});
alSourcefv(source, AL_ORIENTATION, {0,0,1, 0,-1,0});
alGetSourcefv(source, AL_DIRECTION, dir);
// dir is now {0,0,1} (last modified by AL_ORIENTATION)

alSourcefv(source, AL_ORIENTATION, {0,0,-1, 0,-1,0});
alSourcefv(source, AL_DIRECTION, {0, 0, 0});
alGetSourcefv(source, AL_DIRECTION, dir);
// dir is now {0,0,0} (last modified by AL_DIRECTION)
alGetSourcefv(source, AL_ORIENTATION, ori);
// ori is now {0,0,-1, 0,-1,0} (unaffected by AL_DIRECTION)

This is essentially what I do with Alure2's Source::setDirection and 
Source::setOrientation methods -- the former just sets AL_DIRECTION, 
while the latter sets AL_DIRECTION and AL_ORIENTATION -- so an app only 
needs to worry about setting the orientation regardless (with direction 
still being there for compatibility, in case apps only have a "at" 
vector to supply for sources).

I'm curious if this approach would work, or if the direction and 
orientation need to remain completely separate and apps just need to 
deal with it?

More information about the openal mailing list