Hello,
I have a problem since UE5.3 with FMOD. I had this very early on and i searched everywhere but cannot find a solution to this problem. See, I use a granular synth. I also had this problem with the AudioMotors plugin. As soon the frametime was variable ingame and i set the RPM properties of an FMOD Event with this plugin, it produced a nasty sound, like it was drunk. So the release of UE5 was a huge relief because it has the async fixed timestep physics which i abused to update the RPM value of my FMOD events every 4th tick. It went very well until UE5.3, where something broke in the physics engine (which I can proof).
This is what engines sound like on UE5.3. Drunk. Weird. I cannot say what it is. So today i tested for 6 hours different things. I created a new FRunnable thread in UE5.2 which ticks every 16.667ms, so 60 frames per second. The number is not arbitrary but because I do other calculations here that rely on the 60 frames and a timeframe…a lot of things are involved here. So in UE5.2 I get a super clean sound. So I recompiled the whole project for UE5.3 and downloaded the correct FMOD plugin for it and there it is again. You can hear it in the video. But this time I know that Unreal Engine cannot be the problem child because it is my own thread I created.
while (!bShutdown)
{
std::chrono::time_point<std::chrono::steady_clock> Time = std::chrono::high_resolution_clock::now();
const std::chrono::duration<double, std::milli> Duration = Time - LastTime;
if (Duration.count() > DeltaTime)
{
LastTime = Time;
for (int32 i = 0; i < Cars.Num(); ++i)
{
if (!Cars[i] || !Cars[i]->IsValidLowLevel() || !Cars[i]->bTickPhysics) continue;
Cars[i]->MotorAudioMix->NativeAsyncTick();
}
UE_LOG(LogTemp, Display, TEXT("AudioThreadHelper Run %fms"), Duration.count());
}
}
return 0;
So inside the “NativeAsyncTick()” I do all the necessary calcualtions. This is the naive approach where i just tick until the correct delta time is reached, I also tried
FPlatformProcess::Sleep()
to just wait till the next desired ticktime.
I always thought I just have to set the FMOD event float value at a fixed interval but it is not the case? I don’t understand. Also inside the granular synth plugin i followed the FMOD pattern from the examples, with get() and set() methods for each variable and you only set the target values and the plugin internally grabs them when necessary and buffers them into current values. I am really out of ideas on this one.
Best regards.
Hi,
Just to clarify, is the following correct?
- UE 5.2 with the default thread works correctly, until frametime is variable
- UE 5.3 with the async fixed timestep doesn’t work
- UE 5.2 with your FRunnable thread works, until frametime is variable
- UE 5.3 with your FRunnable thread doesn’t work
There shouldn’t be any difference between the FMOD libs used for 5.2 and 5.3, and as far as I can tell there’s no significant changes to the integration code that might cause this - changes to the integration code are fairly small between versions, besides the addition of Niagara support. I would suspect that maybe this issue is being caused by an interaction between the async fixed timestep and what is happening in NativeAsyncTick(), but it’s difficult to say.
This should be the case, but if you want to verify the parameter value of an event instance, you can record a session in the profiler while connected by live update.
Hi, thank you for the reply.
UE5.2 works in the async physics tick and the FRunnable, no matter how the gamethread fps is. Except IO is blocking the whole computer while streaming levels, then for a frame or two everything collapses but this is in editor only so that is not a problem.
in UE5.3 it doesnt work correctly in any thread. To be sure, a session I record should look like this?
I can record also a session in UE5.3 then, just takes a while to convert it. Is there anything special I should pay attention to?
Edit: I simply right clicked my UE5 project file, switched to 5.3, replaced in the project folder the FMOD plugin with 5.3, changed
DefaultBuildSettings = BuildSettingsVersion.v2;
to
DefaultBuildSettings = BuildSettingsVersion.Latest;
and recompiled the project. I recorded a session on 5.3 now. Should I upload the profiler sessions or…? If you want I can also grant you full access to the source code of the plugin and the project in case that would help.
Best regards.
Edit2:
When I press simulate I can hear just the plugin very very loud and without the channel frequency set from unreal engine, so it is very high pitched (it would be amazing if you could add the option to manually set a channel frequency in fmod but still allow auto detection of the sample rate). I read in the docs that in this mode it sounds like played through fmod. in this mode i can super clearly hear the problem.
Here is the result:
I also tried to set the rpm value from the normal tick of the car actor (in the game thread) and that doesn’t help.
How can I log from the plugin to the unreal engine console?
I found it. after days of banging the head against the wall: It is the Doppler effect. as soon as i turn it on everything breaks.
The car physics do tick in the" async physics tick thread", also we tried post and pre physics tick for normal tick events. Uhm ya, it would be great if you can take a look at that. Maybe the position that FMOD receives is not the correct one at the time.
I’m happy to hear that you managed to resolve the issue.
If you’re using integration code to provide FMOD with 3d attributes for your engine event, FMOD should be receiving that info directly from UE’s physics, so it’s likely a change on their end between 5.2 and 5.3 that is causing this.
That said, if you manually override the velocity provided to FMOD with Studio::EventInstance::set3DAttributes and set the vector to be constant, does the issue still occur?
