0
0

System::setFileSystem is used to set the file callbacks the low level system uses for Open/Seek/Read of files. It provides a place for two optional entries, AsyncRead and AsyncCancel to allow for non-blocking file IO. The Unreal plugin, sadly, doesn’t implement these calls. Because of this, FMod threads stall a lot on our PS/4 builds.

The reason is that when an FMod thread makes a call into say FFModFileSystem::OpenCallback, that request first blocks on access to the FMOD File Access Coordinator thread’s mCommand to submit its request, then once any previous command has completed it blocks again on the FMODFAC getting swapped in, doing the command and triggering its command complete event. Then we have to wait for the calling thread to get swapped in and return to FMod. Oof. This cycle happens for every 2K read as well.

I started putting calls to FPlatformTime::Seconds() before and after all these calls, and these stalls can easily take 10’s of ms, and I’ve seen over 100ms on many occasions if there’s other disk IO going on or lots of other activity in the game. This can’t be good.

I’ve been looking around for examples of doing the Async versions so we don’t stall, but I can’t find any guidance on what to do. Has anyone done this Unreal?

Thanks,
Rick

  • You must to post comments
0
0

Async callbacks only benefit streaming sounds, much of the FMOD file IO must be serviced immediately. The reason we have a thread coordinator is due to the Unreal file system not being thread safe.

If you are able to provide a PS4 Razor capture showing the stalling behavior, we can take a look an see what’s happening.

  • You must to post comments
Showing 1 result
Your Answer

Please first to submit.