AL_SOURCE_RELATIVE Doppler shift divergence in OpenAL 1.1 when listener velocity is non-zero

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?