Platform Details | Windows

17. Platform Details | Windows

Windows Specific Starter Guide

SDK Version

FMOD is compiled using the following tools.

  • Visual Studio 2019 - version 16.11.0 targeting platform toolset v142.

Compatibility

FMOD supports the below architectures back to Windows 7.

  • x86 - optimized with SSE3.
  • x64 - optimized with SSE3 (and AVX if detected at runtime).
  • ARM64 - optimized with NEON.

Libraries

The provided libs are import libraries which require the corresponding DLL to be present at runtime. Substitute $ARCH your desired architecture from the 'Compatibility' list above.

The C API of the supplied libraries are compatible with MinGW (C++ ABI not supported). The 64 bit dll can be linked directly. You will need to use the import library libfmod.a and libfmodstudio.a in order to link the 32 bit dlls.

If you encounter issues linking fmod with MinGW, ensure that you are following the GCC linker ordering requirements and the MinGW library search order.

Core API library

  • /api/core/lib/$ARCH/fmod_vc.lib - Release binary for production code (requires fmod.dll at runtime).
  • /api/core/lib/$ARCH/fmodL_vc.lib - Release binary with logging enabled for development (requires fmodL.dll at runtime).

Studio API library (used in conjunction with the Core API library)

  • /api/studio/lib/$ARCH/fmodstudio_vc.lib - Release binary for production code (requires fmodstudio.dll at runtime).
  • /api/studio/lib/$ARCH/fmodstudioL_vc.lib - Release binary with logging enabled for development (requires fmodstudioL.dll at runtime).

COM

Before calling any FMOD functions it is important to ensure COM is initialized. You can achieve this by calling CoInitializeEx(nullptr, COINIT_APARTMENTTHREADED) on each thread that will interact with the FMOD Engine. This is balanced with a call to CoUninitialize() when you are completely finished with all calls to FMOD.

If you fail to initialize COM, FMOD will perform this on-demand for you issuing a warning. FMOD will not uninitialize COM in this case so it will be considered a memory leak.

To ensure correct behavior FMOD assumes when using the WASAPI output mode (default for Windows Vista and newer) that you call System::getNumDrivers, System::getDriverInfo and System::init from your UI thread. This ensures that any platform specific dialogs that need to be presented can do so. This recommendation comes from the IAudioClient interface docs on MSDN which state:

In Windows 8, the first use of IAudioClient to access the audio device should be on the STA thread. Calls from an MTA thread may result in undefined behavior.

ASIO and C#

If using FMOD_OUTPUTTYPE_ASIO with the C# wrapper, FMOD will need to be running on the STA thread to ensure COM is intialized correctly. This can be achieved by adding the STAThreadAttribute to the main method:

ARM64

Building for ARM64 requires Visual Studio 2019 with toolset v142 and supports NEON.

Codec Support

The following are not supported:

  • WMA file format support

DSP Effect Support

The following are not supported:

  • VST format plug-ins

Output Mode Support

The following are not supported:

  • ASIO output mode

Thread Affinity

All threads will default to FMOD_THREAD_AFFINITY_CORE_ALL, this is recommended due to the wide variety of PC hardware but can be customized with Thread_SetAttributes.

Thread Priority

The relationship between FMOD platform agnostic thread priority and the platform specific values is as follows:

Port Support

Windows supports the following port types when using FMOD_OUTPUTTYPE_WINSONIC:

Background Music

The background music will bypass the operating system's virtual speaker processing.

Below is a usage demonstration with error checking omitted for brevity:

FMOD::ChannelGroup *bgm;
system->createChannelGroup("BGM", &bgm);
system->attachChannelGroupToPort(FMOD_PORT_TYPE_MUSIC, FMOD_PORT_INDEX_NONE, bgm);

FMOD::Channel* channel;
system->playSound(music, bgm, false, &channel);

Pass Through

Use this port to bypass the operating system's virtual speaker processing for non-diegetic sounds.

Below is a usage demonstration with error checking omitted for brevity:

FMOD::ChannelGroup *passthrough;
system->createChannelGroup("PASSTHROUGH", &passthrough);
system->attachChannelGroupToPort(FMOD_PORT_TYPE_PASSTHROUGH, FMOD_PORT_INDEX_NONE, passthrough);

FMOD::Channel *channel;
system->playSound(your_non_diegetic_sound, passthrough, false, &channel);

Object Spatialization for 3D Audio (Windows Sonic)

Platform-specific object spatialization technologies can potentially offer more accurate spatialization than the FMOD spatializer effect. To take advantage of Windows Sonic to spatialize your events, you can use an FMOD object spatializer effect instead of an FMOD spatializer. Doing so bypasses any subsequent effects or sends, instead routing the event's audio from the FMOD object spatializer directly to Windows Sonic for object spatialization.

Most platforms can only handle a limited number of object-spatialized sounds, so the FMOD object spatializer effect is best reserved for use with important events.

Your machine must be configured to enable Windows Sonic. To enable Windows Sonic on Windows:

  • Ensure that you are running Windows 10 Creators Update or later.
  • Open the control panel, and click on the sound icon. (If the sound icon does not appear, click on the hardware and sound category.)
  • In the playback tab of the sound window, right-click on your default audio device to open the context menu, then select "properties."
  • In the spatial sound tab of the properties window for your default audio device, open the spatial sound format dropdown menu and select "Windows Sonic" or "Windows Sonic for Headphones."
  • Click the OK button or the apply button to confirm the change.

For more information about object spatialization, see the Spatialization Options and Auditioning Object Spatialization and Height Panning sections of the FMOD Studio User Manual and the Spatial Audio section of the Core API Spatializing Sounds.

Performance Reference

This section is a companion for the CPU Performance section of the Managing Resources in the Core API chapter and serves as a quick reference of facts targeting this platform.

Format Choice

Each compression format provided in FMOD has a reason for being included, the below list will detail our recommendations for this platform. Formats listed as primary are considering the best choice, secondary formats should only be considered if the primary doesn't satisfy your requirements.

  • Vorbis: Primary format for all sounds.
  • FADPCM: Secondary format if Vorbis CPU usage is too high for low spec machines.
  • PCM: Not recommended.
  • XMA: Unavailable.
  • AT9: Unavailable.

Channel Count

To give developers an idea about the costs of a particular format we provide synthetic benchmark results. These results are based on simple usage of the Studio API using recommended configuration settings.

Settings

  • Real channel count: 64
  • Sample rate: 48 kHz
  • Speaker mode: Stereo
  • DSP block size: 1024 samples

Test Device

  • CPU: Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz
  • OS: Microsoft Windows [Version 6.1.7601]

Results

  • DSP with Vorbis: 6.88% (+/- 0.52%)
  • DSP with FADPCM: 3.10% (+/- 0.20%)
  • DSP with PCM: 1.59% (+/- 0.24%)
  • Update at 60 FPS: 0.82% (+/- 0.05%)