Great topic. The biggest gotcha I’ve hit between the two is where each engine does its DSP work and what happens when the real-time thread gets starved. Wwise routes everything through its own sound engine thread with a fixed internal mix rate and a fairly rigid DSP chain, which is great for predictable latency but means any blocking work on your game thread—especially memory allocation or locking a mutex that the audio thread also touches—shows up immediately as underruns and pops. FMOD’s Studio layer is more forgiving on that front because its DSP network is dynamically allocated and you can push heavy processing onto custom DSP stages with explicit priority flags, but that flexibility is exactly where footguns live: if you write a DSP that allocates on the audio thread or does a blocking read, you’re going to get stutter that’s maddening to reproduce. One thing that trips people up with FMOD specifically is that the FMOD::System::update() call has to happen on a non-real-time thread and in a consistent time slice—if your frame spikes, the audio thread can’t keep up and you hear the classic fill-in artifacts. I always profile both with the thread names visible in the OS profiler (Windows Thread Viewer or py-spy/perf depending on the platform) because the audio thread’s actual runtime tells you more than any engine’s own stats.
For root-causing, start by separating “engine can’t keep up” from “engine is misconfigured
