Quantcast

AL_SOURCE_RELATIVE behavior

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

AL_SOURCE_RELATIVE behavior

Chris Robinson-5
Hey guys. I'm hoping to get some clarification on something.

Up to now I had been working under the assumption that the AL_SOURCE_RELATIVE
source property made the source completely relative to the listener. That is,
a position of {0,0,0} would always be at the listener and {0,0,-1} would
always be in front in front of it, while a direction of {1,0,0} would always
face to the right of the listener, a velocity of {0,0,0} would always match
the listener's velocity, etc.

Reading the 1.1 spec, it says this:

"AL_SOURCE_RELATIVE set to AL_TRUE indicates that the position, velocity,
cone, and direction properties of a source are to be interpreted relative to
the listener position."

Now, although it says it makes the source's position, velocity, cone, and
direction properties relative to the listener position, the source's velocity
and direction (and cone) are not affected by the listener position, just the
source's position in relation to the listener position. That, coupled with the
idea of what a relative source should be, can easily lead people to assume the
source properties are simply relative to the listener as a whole.


Taking a literal reading of the spec, however, this would essentially mean
that AL_SOURCE_RELATIVE only affects the source position, making its value
relative to the listener position, and that's it. The velocity and direction
properties would still be interpreted as "absolute" (not relative) vectors,
and the listener's orientation and velocity would still have an effect on the
source's output.

Assuming this literal interpretation, it brings up some really big problems
that undermine its usefulness. For instance, setting a source's position to
{0,0,-1} with it's relative flag set will still cause the sound to pan around
as the listener orientation changes, instead of having the sound come from in
front of the listener/viewer. The only useful position a source can be set to
is {0,0,0} unless you manually update the source position to always keep it
relative to the listener orientation. Same thing with the source's direction.

Additionally, changing the listener's velocity will cause all relative sources
to change in pitch, even if the source is left at {0,0,0}. The only way to fix
this is, again, keeping the source's velocity updated based on the listener's
velocity.

Ultimately this would mean the application has to keep source properties
updated based on the listener properties, even though the idea of making a
source relative to the listener is that such a thing happens automatically. A
lot, if not all, of the work is still left to the application outside of a
very specific use-case (a completely centered sound that can deal with doppler
shift).

Worse still, because of the asynchronous nature of OpenAL, an internal update
can occur in-between modifying the listener and sources, causing a short
moment where a relative source is heard incorrectly positioned, attenuated, or
pitched. So even if an app does try to work around these problens, there is no
way around these occasional glitches.


So, I'm seeking clarification to check if this very narrow utility is what
AL_SOURCE_RELATIVE was really meant for. Or, if possible, to have it clarified
that the source properties are supposed to be completely relative to the
listener as one would assume of a relative source.

As it is, some time between OpenAL Soft 1.3 and 1.4 (about 3 to 4 years ago) a
change was made so that the source was interpreted to be relative to the
listener position and orientation, and it's been that way ever since. A more
recent change (I'm not sure exactly when) made it so the source velocity was
also interpreted to be relative to the listener velocity (with a change just
yesterday to make this more accurate).

It will be easy enough for me to add a compatibility flag that, much like
__ALSOFT_HALF_ANGLE_CONES, restores the old behavior for apps that really rely
on it (though I'm not aware of any that actually do) and keeps the current
behavior as default. I'd much rather do it this way because of how useless and
buggy the old behavior could be.

- Chris
_______________________________________________
Openal-devel mailing list
[hidden email]
http://opensource.creative.com/mailman/listinfo/openal-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AL_SOURCE_RELATIVE behavior

Erik Hofman
On Sat, 2012-03-10 at 15:02 -0800, Chris Robinson wrote:

> Hey guys. I'm hoping to get some clarification on something.
>
> Up to now I had been working under the assumption that the AL_SOURCE_RELATIVE
> source property made the source completely relative to the listener. That is,
> a position of {0,0,0} would always be at the listener and {0,0,-1} would
> always be in front in front of it, while a direction of {1,0,0} would always
> face to the right of the listener, a velocity of {0,0,0} would always match
> the listener's velocity, etc.
>
> Reading the 1.1 spec, it says this:
>
> "AL_SOURCE_RELATIVE set to AL_TRUE indicates that the position, velocity,
> cone, and direction properties of a source are to be interpreted relative to
> the listener position."
>
> Now, although it says it makes the source's position, velocity, cone, and
> direction properties relative to the listener position, the source's velocity
> and direction (and cone) are not affected by the listener position, just the
> source's position in relation to the listener position. That, coupled with the
> idea of what a relative source should be, can easily lead people to assume the
> source properties are simply relative to the listener as a whole.

My interpretation has always been that all sources are to be realigned
such that the listener is located at { 0.0, 0.0, 0.0 } and (the listener
is) facing { 0.0f, 0.0f, -1.0f,  0.0f, 1.0f, 0.0f }. Anything else would
make it almost impossible to use matrix functions internally.

So I would say all properties are relative to the listeners equivalent.

Erik

_______________________________________________
Openal-devel mailing list
[hidden email]
http://opensource.creative.com/mailman/listinfo/openal-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AL_SOURCE_RELATIVE behavior

Eric Wing
In reply to this post by Chris Robinson-5
I'm glad you brought this up. I thought I complained about this a very
long time ago on a list, but I can't remember any more.

Yes, I was trying to use AL_SOURCE_RELATIVE to disable effects for a
particular source. But my listener was moving and I think I kept
getting Doppler effects that I didn't want.

I tried things like you described to work around it, where I would
quickly change the listener values for the particular source and then
change them back, and I do recall it was glitchy at best.

I think I gave up and played a stereo sample instead.


I would like to see this deficiency addressed/fixed in OpenAL.

(Though I'm wondering if what I really want/need is simply a flag that
turns off effects for a source.)

Thanks,
Eric

--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/


On 3/10/12, Chris Robinson <[hidden email]> wrote:

> Hey guys. I'm hoping to get some clarification on something.
>
> Up to now I had been working under the assumption that the
> AL_SOURCE_RELATIVE
> source property made the source completely relative to the listener. That
> is,
> a position of {0,0,0} would always be at the listener and {0,0,-1} would
> always be in front in front of it, while a direction of {1,0,0} would always
> face to the right of the listener, a velocity of {0,0,0} would always match
> the listener's velocity, etc.
>
> Reading the 1.1 spec, it says this:
>
> "AL_SOURCE_RELATIVE set to AL_TRUE indicates that the position, velocity,
> cone, and direction properties of a source are to be interpreted relative to
> the listener position."
>
> Now, although it says it makes the source's position, velocity, cone, and
> direction properties relative to the listener position, the source's
> velocity
> and direction (and cone) are not affected by the listener position, just the
> source's position in relation to the listener position. That, coupled with
> the
> idea of what a relative source should be, can easily lead people to assume
> the
> source properties are simply relative to the listener as a whole.
>
>
> Taking a literal reading of the spec, however, this would essentially mean
> that AL_SOURCE_RELATIVE only affects the source position, making its value
> relative to the listener position, and that's it. The velocity and direction
> properties would still be interpreted as "absolute" (not relative) vectors,
> and the listener's orientation and velocity would still have an effect on
> the
> source's output.
>
> Assuming this literal interpretation, it brings up some really big problems
> that undermine its usefulness. For instance, setting a source's position to
> {0,0,-1} with it's relative flag set will still cause the sound to pan
> around
> as the listener orientation changes, instead of having the sound come from
> in
> front of the listener/viewer. The only useful position a source can be set
> to
> is {0,0,0} unless you manually update the source position to always keep it
> relative to the listener orientation. Same thing with the source's
> direction.
>
> Additionally, changing the listener's velocity will cause all relative
> sources
> to change in pitch, even if the source is left at {0,0,0}. The only way to
> fix
> this is, again, keeping the source's velocity updated based on the
> listener's
> velocity.
>
> Ultimately this would mean the application has to keep source properties
> updated based on the listener properties, even though the idea of making a
> source relative to the listener is that such a thing happens automatically.
> A
> lot, if not all, of the work is still left to the application outside of a
> very specific use-case (a completely centered sound that can deal with
> doppler
> shift).
>
> Worse still, because of the asynchronous nature of OpenAL, an internal
> update
> can occur in-between modifying the listener and sources, causing a short
> moment where a relative source is heard incorrectly positioned, attenuated,
> or
> pitched. So even if an app does try to work around these problens, there is
> no
> way around these occasional glitches.
>
>
> So, I'm seeking clarification to check if this very narrow utility is what
> AL_SOURCE_RELATIVE was really meant for. Or, if possible, to have it
> clarified
> that the source properties are supposed to be completely relative to the
> listener as one would assume of a relative source.
>
> As it is, some time between OpenAL Soft 1.3 and 1.4 (about 3 to 4 years ago)
> a
> change was made so that the source was interpreted to be relative to the
> listener position and orientation, and it's been that way ever since. A more
> recent change (I'm not sure exactly when) made it so the source velocity was
> also interpreted to be relative to the listener velocity (with a change just
> yesterday to make this more accurate).
>
> It will be easy enough for me to add a compatibility flag that, much like
> __ALSOFT_HALF_ANGLE_CONES, restores the old behavior for apps that really
> rely
> on it (though I'm not aware of any that actually do) and keeps the current
> behavior as default. I'd much rather do it this way because of how useless
> and
> buggy the old behavior could be.
>
> - Chris
> _______________________________________________
> Openal-devel mailing list
> [hidden email]
> http://opensource.creative.com/mailman/listinfo/openal-devel
>
_______________________________________________
Openal-devel mailing list
[hidden email]
http://opensource.creative.com/mailman/listinfo/openal-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AL_SOURCE_RELATIVE behavior

Jason Daly
In reply to this post by Erik Hofman
On 03/11/2012 05:30 AM, Erik Hofman wrote:

> On Sat, 2012-03-10 at 15:02 -0800, Chris Robinson wrote:
>> Hey guys. I'm hoping to get some clarification on something.
>>
>> Up to now I had been working under the assumption that the AL_SOURCE_RELATIVE
>> source property made the source completely relative to the listener. That is,
>> a position of {0,0,0} would always be at the listener and {0,0,-1} would
>> always be in front in front of it, while a direction of {1,0,0} would always
>> face to the right of the listener, a velocity of {0,0,0} would always match
>> the listener's velocity, etc.
>>
>> Reading the 1.1 spec, it says this:
>>
>> "AL_SOURCE_RELATIVE set to AL_TRUE indicates that the position, velocity,
>> cone, and direction properties of a source are to be interpreted relative to
>> the listener position."
>>
>> Now, although it says it makes the source's position, velocity, cone, and
>> direction properties relative to the listener position, the source's velocity
>> and direction (and cone) are not affected by the listener position, just the
>> source's position in relation to the listener position. That, coupled with the
>> idea of what a relative source should be, can easily lead people to assume the
>> source properties are simply relative to the listener as a whole.
> My interpretation has always been that all sources are to be realigned
> such that the listener is located at { 0.0, 0.0, 0.0 } and (the listener
> is) facing { 0.0f, 0.0f, -1.0f,  0.0f, 1.0f, 0.0f }. Anything else would
> make it almost impossible to use matrix functions internally.
>
> So I would say all properties are relative to the listeners equivalent.


I have to believe that the more useful, less literal interpretation is
what was originally intended.  The listener's local coordinate system
essentially becomes the origin for all SOURCE_RELATIVE sources.  This
would include velocities, so a SOURCE_RELATIVE velocity of (0, 0, 0)
would match the listener's velocity exactly, as Chris pointed out.

As Erik says, anything else would make the use of matrix-based functions
impossible.  It would also lead to undesired emergent properties (like
Eric pointed out).

Perhaps instead of interpreting the specs "the listener's position" as
the listener position and nothing but the position, it should be
interpreted more broadly as "the listener's local coordinate system,"
which would be defined to include position, velocity, and orientation.

Obviously this should be clarified if we ever get to making a new spec!

--"J"
_______________________________________________
Openal-devel mailing list
[hidden email]
http://opensource.creative.com/mailman/listinfo/openal-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AL_SOURCE_RELATIVE behavior

billy
This post has NOT been accepted by the mailing list yet.
Unfortunately it seems that vendors (such as Apple) are satisfied with the base OpenAL functionality in OpenAL 1.1 and there have been no real updates to the API or documentation since it seems to work "well enough."

Well, yes it seems to work well enough but it needs to be maintained as well.

Even the official documentation seems to have all but disappeared, and you can scarcely find old PDFs (the one called OpenAL_Programmers_Guide.pdf) cached in old places on the net.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AL_SOURCE_RELATIVE behavior

billy
This post has NOT been accepted by the mailing list yet.
Actually, in the OpenAL 1.1 implementation on iOS at least, I can confirm that setting a sound to AL_SOURCE_RELATIVE works as expected.

That is, if you set a source to AL_SOURCE_RELATIVE, play it at (0,0,0), and then move LISTENER around, the source remains with the listener (as you should expect it would).

If you play a source with AL_SOURCE_RELATIVE at (1, 0, 0), then ROTATE the listener, however, the source DOES NOT REMAIN TO THE RIGHT OF THE LISTENER.

Loading...