Profiling Audio

Overview

There are several ways to profile sound and music and investigate different technical aspects. Here is an overview.

Memory

Sound memory is managed as a cache within static or rather dynamic sizes. If a static memory block is allocated then it is spent no matter how much audio data is stored. Sometimes old and unused data needs to be unloaded (trashed), before new data can be stored.

Therefore, the goal is to find a good balance between cache size and trashing. Depending on the platform, memory can be divided into different types and uses:

Memory Type	Description
System Memory	With the transition to memory pools the system memory that is located in main memory is used to store data that the SoundSystem needs to function correctly.
Primary Sound Memory	Sound, music, DSP, and voice data is stored in this area of main memory. It is planned to fully flush this memory during level load.
Secondary Sound Memory	On PlayStation 3 this memory is located through the graphics processor. It's slower to access but can be combined with the precious main memory. On Xbox 360 physical memory has to be used for direct XMA decoding instead of the main memory, which can be "virtual". On the PC there is no need to use this memory type.

Memory Type

Description

System Memory

With the transition to memory pools the system memory that is located in main memory is used to store data that the SoundSystem needs to function correctly.

Primary Sound Memory

Sound, music, DSP, and voice data is stored in this area of main memory. It is planned to fully flush this memory during level load.

Secondary Sound Memory

On PlayStation 3 this memory is located through the graphics processor. It's slower to access but can be combined with the precious main memory.

On Xbox 360 physical memory has to be used for direct XMA decoding instead of the main memory, which can be "virtual". On the PC there is no need to use this memory type.

MemStats

MemStats n queries all modules in CRYENGINE to report back their used memory every second. It is not recommended to use values lower than 1000 as it would output too much data to make the readout manageable.

You can scroll up and down in the view with the arrow keys. Use MemStatsMaxDepth to change the amount of details presented. CrySoundSystem is the main entry for Audio. You can easily find Sound and Music memory usage sorted under this entry.

MemInfo

MemInfo 1 presents a table of different modules and allocation statistics. Find the CrySoundSystem.dll row. The purple column shows the total number of allocations. Run-time allocations should be avoided by all modules.

CPU Time

Load

The CPU used to be the main processing unit, but modern platforms use a more parallel architecture. Typically saying something is "expensive" or "too long" describes the time the main thread is exclusively busy with a task. For Audio many things happen on different threads or even different computation units. Still, this time is precious and needs to be monitored. As an example for the time budgets consider 1000ms , and a target frame rate of 50, which leaves 20ms to compute, render, and display a frame. Out of this 20ms about 3-4ms are given for sound, music, voices, dsp, obstruction, reverb, soundmoods and mixing.

Stalls

When the main thread is blocked for a long time, the whole game stalls resulting in choppy frame rates.

Profiler

The Profile offers a wide variety to look at timings of modules and how long they exclusively block the main thread. Make sure you don't have s_SoundInfo enabled, when profiling as this has a significant effect on the numbers.

Use "profile 1" to get a list of functions, or "profile 6" for a short list of the modules.

Use "profile_filter Sound" or "..Music" to filter out other modules.

Use "profile_peak" to control the threshold of reporting stalls.

Stalls are reported on the left hand side when they exceed 10 ms, but you can set the filter by using profile_peak, for instance 5.

VU Meter

s_VUMeter <mixing category> enables audio volume debug drawing for the selected sound card channels.

Example: "s_VUMeter master" will show the audio output on each channel on the master category of FMOD.

Sound Management

Managing the sounds that are requested, playing, inactive, virtual, or fighting for a free FMOD slot in an efficient way is an important factor. There are ways to show what is going on in the SoundSystem to understand if a situation is performing well, or if something is going poorly.

s_SoundInfo 1 provides basic information about the size of caches and pools on the top of the screen, shows how many events are playing, how many channels are used and how many inactive sounds are handled by the SoundSystem.

Statistic	Description
All	The sum of main memory usage.
Sounds	Sum of actual sound data without meta data.
Main	Sum of meta data stored in main memory.
Cache	Displayed when FMOD operates on a soft capped budget with dynamic allocation.
Static Cache	Displayed when FMOD internally operates on a static memory block.
RSX	Describes Secondary Sound Memory on PS3.
TrashCount	This number shows the number of attempts to unload old sound data because the memory cache is too full. If this number grows constantly, it is a very bad sign. If the channels are constantly above 20, have a closer look where they are spent. If the inactive sounds are fluctuating drastically or exceed 100 have a look where they are, and why so many sounds are created.
s_DrawSounds 1	Draws a red sphere at the location of sound events and its full name.
s_DrawSounds 4	Same as 1 plus additional info. Use this view often, and understand the difference. It is especially useful for locating particle sounds that fight over limited playback slots of an event.
s_DrawSounds 5	Similar to 4 but additionally shows event specific parameters, their current values plus min, max boundaries as well as rolloff type used.
s_DebugSound 1	Can be turned on and will print out information in the log or console. If the text scrolls by too quickly to read, check what sounds are getting started and stopped so often.

Optimizing Audio

Shorten all sounds as much and as aggressively as possible without design implications!
Use pitch and volume randomization in the event instead of adding new pitched variation!
Put sound events into groups that are played adjacently in space and time in the level. When the player progresses through the game it's better for the SoundSystem to fully unload these groups and use new ones instead.

If you see a similar warning in the console log as follows, it means that the engine is having to do multiple samples to reach the required target.

It is recommended that you set the operating system sample rate to match CRYENGINE's to avoid this (or set the engine's sample rate via s_FormatSampleRate).

[Warning] <Sound> CryENGINE internal audio sample rate differs from OS level sample rate!
CryENGINE: 48000 OS: 44100

Using the FMOD built-in profiler

Please refer to the FMOD manual page 183 onward for more detail on how to use the FMOD profiler. Here we will give you a brief overview on how to connect the profiler to your game.

First of all you need to start the profiler, do so by navigating to the Window menu in the FMOD designer and click Profiler. The profiler will open in a separate window.

The first thing you need to set is the IP and port of your target machine. You can find this in the upper right corner.

In case you are running the profiler and the target application on the same machine you can leave the default 127.0.0.1 (home) and the default port or enter the IP address of your target platform, e.g. the IP of your Xbox kit.

Please check with your IT department in case there is any problem with ports.

You must also enable network profiling with the s_NetworkAudition 1 CVar in your system.cfg file before starting the Editor.

Once successfully connected you can play around with the different settings to display as much or few information as you desire depending on what you are trying to profile. Again, please have a look in the FMOD manual for more details.