[Openal-devel] AL_SOURCE_RELATIVE behavior

[Eric Wing]

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 <chris.kcat at gmail.com> 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
> Openal-devel at opensource.creative.com
> http://opensource.creative.com/mailman/listinfo/openal-devel
>