I don’t know if it is deliberate or an accident, but according to my profile readings on a PS4, all FMOD-related threads appear to be running on CPU#2. The problem is that CPU#2 is reserved by UE4 for the rendering thread, which is the most critical task (at least that’s true on my project). Just moving the UE4 rendering thread to a different CPU (by modifying file PS4Affinity.h), I observed an overall 50% speed improvement, which is huge! However, I’d like to have FMOD threads moved instead, for example on CPU#4 or #5. This would allow me to run all game threads on CPUs #0 to #3 and thus reduce cluster-switches, which can be very expensive. Since different programmers may have different preferences, would it be possible to add, in a future version of the UE4 integration, the possibility to specify the thread affinity mask for FMOD-create threads?
Apparently fmod can even starve itself and cause streaming playback to stutter if you load a large number of banks.
Why is fmod artifically limiting all its threads to a single cpu? Whats even the point of allocating 7 separate threads and then making them all run on 1 cpu?
Besides that, the thread priority has the load thread above playback related threads. So… if you are playing music or dialog during a loading screen, and load some banks = starve playback and audio stutters.
Game developers don’t want the audio system to run on all CPUs available. They generally prefer audio runs on 1 cpu, even if it is on multiple threads. A CPU can have threads with multiple priorities of varying levels. So generally FMOD does not ‘starve’ itself. In the old days there was only 1 CPU and FMOD had no problem running on multiple threads on one CPU. If you want t configure it differently from the default please use the affinity functions provided to you. This is generally only an issue if the game wants to use the same CPU and load it heavily, which in turn can starve the audio.
For the console platforms, FMOD by default puts all threads onto core 2, but there is an init time function that can assign affinity to each thread. The function to do that is FMOD_Orbis_SetThreadAffinity in the private file fmodorbis.h. We currently don’t include that header with our UE4 PS4 integration, but it does ship with the programmers API for PS4. We’ll start including the header for next patch UE4 release.
If you want to customize the thread affinity yourself, you can download the programmer API for PS4, drop the orbis header into FMODStudio/Public/FMOD/, and add a call to set the affinity in the FFMODStudioModule::CreateStudioSystem function.
Ideally it would be exposed via the Settings window with no code changes needed. We have a task coming up to expose more init time settings this way, and we’ll make sure thread affinity is done then as well. I don’t have an exact ETA when we’ll do that task though.
Thanks for the info. I will try that for the time being, while waiting for an “official” support. While working on the UE4 integration, you might want to avoid having CPU2 as the default, since, as I said, it’s also the default for the critical rendering thread.