No, as I said, our EQ filter is just the basic XAudio2 built-in EQ effect. There’s pretty much nothing we can do to make it more performant than it is since it’s black-box.
Here’s the built-in xaudio2 effects:
https://msdn.microsoft.com/en-us/library/windows/desktop/ee415726(v=vs.85).aspx
Here’s the params:
And if you want to look at how we set it up, check out XAudio2Effects.cpp. Basically, it creates a pre-master submix voice with the EQEffectChain and routes audio to it if enabled.
The issue I found was in:
FXAudio2EffectsManager::SetEQEffectParameters
Where there’s hard-coded params for the 4th band – i.e. the 4th band can never have anything but a fc of 10k. My “fix” is to just to expose all the params of the EQ effect. I haven’t checked it in yet because we’re doing testing/stabilization from our internal dev branch. I’ll send you a CL once I check that fix in.
As I said, my suspicion is AMD audio devices are doing something that other devices aren’t and is requiring more CPU time per audio block.
Their AMD TrueAudio feature page suggests as much:
http://www.amd.com/en-us/innovations/software-technologies/trueaudio
It’s likely that the EQ effect is just the “feather” on the back of the CPU camel that is pushing your stuff over the edge and causing buffer underruns.
Have you guys written custom audio code to get VOIP 3D-spatialization? Are there any thread synchronization issues between the main thread in your VOIP procedural voice (either in audio capture side or rendering)? If so, I’d suggest removing any critical sections or other blocking synchronization mechanisms and use a lockless queue or some other lockless mechanism to get any main-thread data (e.g. position information) to any of your custom code.