I’m often rendering with a framerate above 60Hz, say around 160Hz in my case.
I call FMOD::Studio::System::Update() for every rendered frame, so around 160Hz. This results in crackling sound with seemingly mostly when the listener and sound objects are moving at around 100 km/h (~28 m/s or 28 units/sec for FMod).
It’s not exactly crackling like in a buffer underflow, it’s more like 3D positioning is off; the sound position seems offset (more to the right instead of in the center of the ears for example). This is evident with both FMod Studio Events and regular FMod Low Level sounds.
If I throttle the Update() calls to cap it around 60Hz, things get better but it doesn’t seem to be quite gone. Adding FMOD_STUDIO_INIT_SYNCHRONOUS_UPDATE when initializing does not help.
Does anybody recognize this? Also somebody calling Update() well over 60Hz where they have no problem?
A little more debugging: the source sound is very close to the listener. The stutter is the switch to the sound being in front of the listener and the sound being at the rear. When doing this by hand by moving the listener back and forth, there is a notable ‘switch’ in the audio when this crossover happens. You would expect a more gradual change when the sound moves from front to rear or in reverse.
I assume the stuttering is the ‘catching up’ of listener vs sound source, so it is close to a fast front/rear switch.
If your sound is flipping through the origin, or through the listener, normally in studio this is handled by ‘sound size’ and ‘extent’.
If in studio you had this set to ‘auto’ then it shouldn’t be flipping from one side to the other, at the 0,0,0 point, it would be morphed into all speakers, then gradually becomes a point source again as you move away from the listener. If it is ‘off’ or ‘user’ (with a small sound size) then it will exhibit this issue.
In the low level API, you can use set3DLevel function as the sound approaches the listener to morph it into a 2d sound (0.), then back to 1.0 to make it a point source 3d sound again.
I’ve had the chance to dive deeper into this; the FMod Studio event was indeed set to ‘user’. Setting it back to ‘auto’ resolved the issue. Thanks for the help!