Version
The audio command queue is the mechanism that relays all API calls from game to the inner sound engine. It is a memory buffer that you can monitor in the Performance Monitor view. When this buffer is full of commands, it will temporarily block the game thread that is trying to add yet another command. This is done to avoid losing API calls which could later lead to synchronization issues between the game and the sound engine. However, this will likely cause a hiccup in the game framerate.
Probable causes:
Too many API calls are made in a single game frame. This is most common reason this error is reported. Usual suspects are redundant calls to SetPosition
, SetRTPCValue
,
SetSwitch
, and the like. This also happen while setting up a "level", creating lots of Game Objects, setting their position and RTPCs before the actual game process starts.
Memory intensive API calls are made, with huge numbers in the parameter arrays (such as SetMultiplePositions
or geometry calls for Spatial Audio).
The audio processing thread is very busy, preventing processing of commands. This error would be accompanied by a Voice Starvation error if that is the case.
The audio processing thread is blocked or deadlocked. This is indicative of a bug in either the game or Wwise itself.
Recommended resolution steps:
Profile the API calls the game is making by enabling API Calls in the Profiler Settings (Alt-G). This can be used to identify which game process is flooding the queue with API calls.
Review the way the game updates the Game Syncs (States, Switches, Game Parameters) for Wwise. Update these only when necessary.
Add intra-game-frame calls to
AK::SoundEngine::RenderAudio
to split a game frame into multiple audio frames. RenderAudio only marks the end of a collection of API calls that pertain to a game frame. It will trigger processing of the Audio command queue to update the internal sound engine state, but no actual audio is rendered by that function call.
Make sure the audio processing thread (named AK::EventMgrThread
, but whose priority is set via AkPlatformInitSettings::threadLEngine
) has a high enough CPU priority to process. If this was the problem, the game would also experience a lot of "Voice Starvation" errors too.
Connect a debugger to the game and validate that the thread named AK::EventMgrThread
is actually running. If it isn't, it would imply the game already lost all sound. If this is the case, contact Audiokinetic Support.
Increase command queue memory size, see AkInitSettings::uCommandQueueSize .
Questions? Problems? Need more info? Contact us, and we can help!
Visit our Support pageRegister your project and we'll help you get started with no strings attached!
Get started with Wwise