Question
AL_SOURCE_RELATIVE Doppler shift divergence in OpenAL 1.1 when listener velocity is non-zero
Dev Maple
0 reputation · 22 Dec 2020, 09:20 UTC
23.2K views1
Loading…
0 reputation · 22 Dec 2020, 09:20 UTC
OpenAL 1.1 defines the AL_SOURCE_RELATIVE source attribute as making source coordinates relative to the listener position, but the specification does not resolve whether listener velocity contributes to Doppler shift calculations when this attribute is enabled. This ambiguity creates divergent behavior across implementations: OpenAL Soft computes Doppler using the relative velocity between source and listener even when AL_SOURCE_RELATIVE=TRUE, treating listener velocity as part of the relative motion, while Creative's historical hardware implementations applied Doppler based solely on source velocity in listener space, ignoring listener motion. Applications requiring consistent pitch perception for UI-attached or HUD sounds must therefore either avoid AL_SOURCE_RELATIVE or implement custom Doppler logic, risking portability issues across software and hardware OpenAL deployments.
The OpenAL 1.1 specification section 3.3.6 describes Doppler factor and velocity references limited to source velocity, with listener velocity discussed only in listener property contexts, not relative-source semantics. No EFX, HRTF, or Khronos-maintained extension clarifies this interaction, leaving the behavioral contract unspecified for implementations targeting both software and hardware platforms.
Does the OpenAL 1.1 specification intend for listener velocity to influence Doppler shift when AL_SOURCE_RELATIVE is TRUE? How do OpenAL Soft and Creative hardware implementations differ in their Doppler computation for relative sources with non-zero listener velocity? What is the expected behavioral contract for applications requiring consistent Doppler pitch across software and hardware OpenAL deployments?
35275 reputation · 22 Dec 2020, 16:07 UTC
The OpenAL 1.1 specification does not explicitly define whether listener velocity should influence the Doppler shift when AL_SOURCE_RELATIVE is set to AL_TRUE. While the specification defines relative coordinates for positioning, it lacks a corresponding behavioral contract for velocity in relative space. This omission creates a gap where implementations must decide if a "relative" source is conceptually attached to the listener's frame of reference (and thus immune to the listener's own motion) or if it remains a physical entity whose relative velocity is still calculated.
Because the specification is silent, two primary behavioral patterns have emerged across common implementations:
openalAL_SOURCE_RELATIVE flag. If the listener has a non-zero velocity, the Doppler effect is applied because the relative motion is non-zero.AL_SOURCE_RELATIVE as a complete attachment to the listener. In these implementations, listener velocity is often ignored for relative sources, effectively treating the source as if it were moving in perfect synchronization with the listener.For applications requiring consistent audio behavior—particularly for HUD or UI elements that must not pitch-shift regardless of the listener's movement—relying on AL_SOURCE_RELATIVE is insufficient for cross-platform portability.
alSourcefv(source, AL_VELOCITY, listenerVelocity);alDopplerFactor(0.0f);To verify the behavior of your current deployment, perform the following test:
AL_SOURCE_RELATIVE to AL_TRUE.(0, 0, 0).(100, 0, 0)).Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 22 Dec 2020, 11:11 UTC
The OpenAL Soft implementation explicitly documents this design decision in alc/alu.c: SOURCE_RELATIVE only affects position; velocity remains in world space for Doppler calculation. This confirms the behavior is intentional, not an oversight. For middleware users, note that FMOD and Wwise OpenAL backends may implement their own SOURCE_RELATIVE semantics differing from both OpenAL Soft and Creative hardware. If you need per-source Doppler control without disabling it globally, check for AL_EXT_SOURCE_DOPPLER_FACTOR support—though it’s not universally available across hardware drivers.