I can’t reproduce it by myself, but I have many reports that at some point, usually after longer gameplay, like hour or more, audio starts hitching (and never stops it, game need to be restarted). It seems this is happening only on some Windows configurations, often on older Intel systems. Anyway there are no Fmod warnings or error in logs. Game is not using any impulse reverbs, and only is using EQ and compressor effects.
I wonder if you had similar reports from other people or you remember changes from like few months ago, like threads or timer changes that can cause this, or maybe some specific Windows Update that maybe causing this?
I will try go get my hands on PC that this is happening and report more if I will be able to reproduce it by myself.
Nothing immediately comes to mind that would explain what you are seeing. It’s possible you have an instance leak that slowly accumulates to the point where the mixer CPU is saturating causing hitching. I’d recommend connecting the FMOD Studio profiler to your game and monitoring the instance numbers.
If you are able to reproduce the issue, that would be ideal, taking a profiler capture when the game is hitching would give a bunch of info. If that’s not possible, adding some calls to Studio::System::getCPUUsage that the user with the issue can trigger might indicate a particular FMOD thread is going over 100%.
It is rare bug and hard to reproduce. It is happening after long playback and only on some busses. Right now I’ve removed all compressors and sidechains from my project and so far bug is gone.
But I have to test it for few more days to be sure that sidechains are causing this.
Anyway also I’ve found another issue. When event instance is paused, then it will not be released properly - at least I can see it in profiler and never disapears, even if max instances limit is reached. But this probably not connected with this issue.
When an event is paused it is considered “not playing” and stealing, which stops events, only applies to events that are currently playing. This is by design. If you start the event it will adhere to the rules you have set for stealing (eg. if set to “oldest” it will stop the event if it was the oldest).
Anyway, it was my fault, two ticks was setting listener position and in very rare cases one tick was first, next frame another and this was causing lisneter to jump each frame to different position and causing enabling and disabling hundreds of virtual voices and causing this “stutter”…