As a Roblox developer, it is currently impossible to exclude the camera’s position delta for processing doppler effect.
As it stands now, when doppler effect is being processed, it takes into consideration the camera’s position delta as well as the listener’s velocity. While this is accurate behaviour (assuming the listener and the camera share the same position), some developers would welcome the option of having the position delta ignored in doppler processing. Personally, I’d like to increase the DopplerScale in one of my games without having minor camera movements heavily detune the audio.
Let’s say for example, I want the camera to tween in on the player when they spawn in. If that player has a boombox blasting tunes, then their song would appear to increase in pitch, since the position delta of the camera results in a net velocity towards the listener.
Another, more common example. Let’s say a sound is playing on the far edge of a map, and the players have their camera positioned really far away from them. If they were to revolve the camera around themselves, they’d hear large increases or decreases in that sound’s pitch, depending on weather the camera is moving closer to or further from the sound source.
Again, this is accurate behaviour, but only when assuming that the listener shares the same position as the camera. In many cases, the developer would opt for the player’s character to be the listener, meaning camera deltas won’t affect the doppler effect. SoundService:SetListener("ObjectPosition", workspace.CurrentCamera.CameraSubject) corrects the doppler effect in the sense that spinning the camera around doesn’t cause insane jumps in pitch, but then audio volume is computed from the listener’s position, meaning that moving the camera away from a sound source for example, won’t reduce that sound’s volume.
I’d propose a simple boolean property parented under the SoundService (“DopplerVelocityOnly” or “VelocityExclusive” perhaps). When true, the velocity of the listener is assumed to be 0 unless the listener is a BasePart (either through Camera.CameraSubject or SoundService:SetListener()), during which BasePart.Velocity is taken into account only. I believe this was how things used to work way (way, waaay) back when, so it’ll be nice if this were an optional feature.
There’s a somewhat-hacky fix to this issue here, but I’m sure we can all agree that the solution would be less complicated and more efficient if it were done natively.