I have received a report from my team’s porting division, and it highlighted some concerns regarding FMOD and its porting risks as follows (target ports are Switch 2, PS5, and Xbox X|S):
Confirmed local evidence points to FMOD Studio 2.02 and the FMOD for Unity 2.02 integration
branch;
The project contains many banks, and several are large, so memory budgeting and streaming
strategy matter on console;
Console readiness will depend on rebuilding/exporting banks per target platform and verifying
native binaries for each platform
I have already done some research and know that in order to proceed I need to:
Rebuild the banks in each designated platform (i.e., adding Project Platforms in Build Preferences option).
Set limits to each event instance and control the stealing behaviour for maximum efficiency.
Convert some long and heavy audio files from .wav to .ogg.
Set event priorities.
Set proper loading modes to assets.
I was wondering if this is enough preparation for the ports. I do have some questions:
I understand that FMOD recommends sticking to the default platform settings for each platforms, but since my game only has stereo mix and no surround, is it okay to change the “Surround Speaker Mode” to Headphones on PS5, Xbox, and Switch?
Is there any advantage to setting the custom platform encoding, specifically the “Advanced Loading Mode,” compared to the ones on platform-specific builds?
What is the safe limit on having multiple “Virtualize” stealing on multiple different events?
Are there any extra steps besides all of these when porting to the platforms mentioned?
Any heavy drawbacks to increasing real voices channels in the FMOD Settings?
I was wondering if there is something I missed, or something I should do; please tell me.
This is my first time preparing and executing FMOD ports, so forgive me if I missed something along the way or asked something that might have been asked multiple times.
Yes. The default settings were chosen because they suit a broad variety of games, but “a broad variety of games” is not “all games.” If your game would benefit from changing the settings to something else your target platform(s) support, you should change that setting.
Yes.
Before I get into that, though, I should mention that all encoding settings are platform-specific, regardless of whether they’re for individual assets, folders of assets, or the platforms themselves. (You’ll notice that if you give an asset custom encoding settings in the assets browser, then change the current platform in the drop-down menu that appears in the bottom-right corner of the window, the encoding setting displayed next to the asset changes; this is because FMOD Studio only displays the encoding settings for the platform that’s currently selected.)
In any case, to answer your question: The encoding settings for a platform are used for all assets that do not have custom encoding settings of their own for that platform. This means that if (for example) some of your assets sound better at lower quality settings than others, you could set those specific assets to use lower quality encoding settings, while keeping the the encoding quality of the other assets in your project high, and thereby save some resources.
Advanced loading mode is no exception to this. If you want a particular asset to use the “streaming” loading mode on one platform and the “decompressed” loading mode on another platform, you can.
I’m not sure what you mean by “safe limit.” There is no limit on how many events you can give the “virtualize” stealing behavior.
Do note that the virtualize stealing mode might not be desireable in all cases. A virtualized sound is an inaudible sound; if you virtualize sounds that would otherwise be audible to the player, the player will hear the sound suddenly falling silent, and will hear it suddenly return to audability if and when the sound is subsequently un-virtualized. This is why most games only virtualize sounds that are so quiet as to be inaudible; or, if visualizing audible sounds is unavoidable, only virtualize sounds that are the quietest in the mix and therefore least likely to be missed.
More broadly, if an event in the project has a stealing mode other than virtualize, setting it to “virtualize” will result in instances of the event being virtualized instead of culled - and the difference between a virtualized event instance and a culled instance is that the virtualized instance can potentially come back. Allowing event instances that were meant to be culled in the original to come back in your ports may be undesireable in some cases, so be sure to test thoroughly.
I can think of a few things that might be relevant.
FMOD Studio supports excluding specific effects and event tracks from specific platforms. (To do so, right-click on an audio track, return track, or effect, the use the “Include on >” submenu of the context menu.) An effect or track excluded on a particular platform is not included in the banks built for that platform and does not consume resources at run time on that platform - meaning that this feature can be used to reduce the size and resource footprint of your game on platforms with more limited available resources. The trade-off of excluding certain of an event’s effects and tracks from a platform is, of course, that the event will sound different on that platform due to having less content. You will have to decide when and whether this trade-off is worth it.
All port bus types are platform-specific, and so if you are porting a game that makes use of port buses, you may need to make some adjustments to your FMOD Studio project. It sounds like you’re porting a PC game to consoles, which makes it unlikely that your game uses port buses currently - but you might want to check out the relevant section of our documentation, just in case you’re planning to make use of one of your target platforms’ port bus-related features (such as controller vibration).
The object spatializer effect relies on platform-specific spatialization technologies found on some consoles, and falls back on the FMOD Spatializer if no such technologies are present. Again, this won’t be relevant if you’re porting a PC game - but if you’re porting a console game, you should be aware that any events that relied on object spatialization may be spatialized subtly differently on your target platforms.
You may want to consider enabling the “build metadata and assets to separate banks” option in the build tab of the preferences dialog, if it is not enabled already. It’s useful in the case that you make a post-release change to the content of an event that doesn’t change the audio files used by that event, since it allows you to issue a patch that only includes the project metadata and not the sampledata as well, significantly reducing the patch’s download size. That can be useful on some consoles.
Since you’re porting to a Microsoft console, we recommend checking the “Align sample data for binary patching, 4KB blocks” checkbox, to ensure more efficient binary patching of banks should the need arise to release a patch.
The more real voice channels you have, the more audible voices your game can play at a time. The trade-off is that every audibly-playing voice consumes resources, and so increasing the maximum number of real voices your game supports may increase its resource footprint.
I should mention that it is unusual for a port to increase the real voice channel limit. Most ports either keep the limit the same (so as to preserve the behavior of the original game as perfectly as possible) or lower it (to save CPU and memory on platforms with more constrained resources.)
It’s actually very useful to us to have such a comprehensive question about porting in our forums, since it becomes a resource we can point other people to when they need help. Thanks for asking it!
Hello, thank you so much for the detailed answer! It gives me more understanding of the process :D.
I’m still quite confused about “building metadata and assets to separate banks”. If I enabled this, can I still edit, for example, change an event’s asset file? Because I thought banks were only supposed to hold the event, the event’s properties, and their relation to the assets they’re using, and not contain the assets themselves?
Sorry for the confusion; I was wondering how far I can push using “virtualize” stealing behaviour on events. I’m using it for looping sounds for objects that are immediately spawned in, never released, or only destroyed after a stage is passed, and not in the camera’s view until the player encounters it. I do know that using “virtualize” will utilize the CPU more, but due to the nature of the sound trigger code only triggers once; this is the only way I see fit. But I was wondering if, for example, there are a lot of virtualized events running simultaneously, could it cause audio stutters? I’m currently having this bug in my game and am still trying to identify the cause.
Correct me if I’m wrong, my understanding of the loading mode is:
“Streaming”: Best used for long assets that usually have just a single event throughout the game, such as music and ambience beds. It utilizes more CPU and has more I/O output because it streams directly from the disk to eliminate asset loading to memory to prevent long loading times or possibly late event triggers.
“Compressed”: The asset is compressed when loaded into memory and decompressed when it’s being called, so it saves memory load but increases the CPU usage a bit.
“Decompressed”: I’m still confused about this one, other than that it’s recommended for mobile platforms. Utilizes less CPU but more memory?
And also, to my understanding, to prepare the FMOD ports for other platforms, I just need to add the platforms wanted and just build it again?
Banks hold everything a game needs to play content designed in FMOD Studio, including both the event metadata (i.e.: “the event, the event’s properties, and their relation to the assets they’re using”) and the sample data (i.e.: the audio assets used by the event, compressed and encoded for efficient loading).
Building metadata and assets to separate banks doesn’t prevent you from changing your events’ asset files. All it does is ensure that the assets and metadata associated with an event are split into two separate bank files instead of all being in the same bank file. This is useful if a patch changes an event’s metadata without changing the assets associated with an event (for example, by tweaking the trigger conditions of an instrument without changing the asset the instrument plays), since it means that only the metadata bank will be different and will need to be included in the patch, while the much larger sample data bank won’t need to be included.
Of course, if a patch does change the assets associated with events, the sampledata bank will be different to the original, and so will need to be included in the patch.
You could safely virtualize every event in your project if you wanted. Such a project would be utterly silent, but would consume far less CPU time than a project that produced sound.
Yes and no. It’s true that virtualized events do consume an amount of CPU time, but it’s much less than they would consume if they were non-virtual. This is because a virtualized event does not require any CPU time to process and mix audio, as it produces no audio that would need to be processed and mixed; as such, a virtualized event only requires the small amount of CPU time required to keep track of its parameter and property values.
No. The resource cost of virtualized assets is almost negligible, and so having a lot of virtualized events is vanishingly unlikely to be a problem.
The most likely cause of audio stutters is having too many streaming assets playing at the same time, or attempting to play streaming assets during times of heavy disk access (such as when loading levels, saving the game, or downloading patches in the background). I recommend setting your streaming assets to not stream, and see if the stuttering stops.
The exact number of streaming assets a platform supports depends on both the encoding formats of the streaming assets and the amount of disk access going on in the background. Since the latter can be hard to predict, we recommend playing only a low single-digit number of streaming assets at any given time, and not playing streaming assets at all while saving or loading significant amounts of content from disk.
If the stuttering continues even when no streaming assets are playing, it must have some other cause. I recommend connecting to your game using live update and recording a profiler session in FMOD Studio, as such a session is useful for diagnosing these kinds of issues.
That’s nearly all correct! There’s just a couple of points of confusion to clear up:
While streaming mode technically can be used to prevent late event triggers, it’s almost never used for that purpose, as events trigger often and only a limited number of streaming assets can be played at the same time. A more common and useful way to prevent late event triggers is to load an event’s sample data in advance of when that event needs to play.
“Decompressed” loading mode increases the amount of CPU time and memory required to load that sample data for playback, but also decreases the CPU cost of playing it once it’s fully loaded. Decompressed loading mode dates back to the time before smartphones, when PDAs and mobile phones had extremely limited processing power yet supported simple games that could be controlled using the face buttons. Modern smartphones are easily powerful enough to handle compressed loading mode, but decompressed loading mode remains as an option for applications with unusually tight resource budgets.
You will also need to set any platform-specific settings relevant to each new platform you add prior to building. That includes any and all compression and encoding settings of assets in the assets browser.
I see. What if my project has already been using the “building metadata and assets to the same banks” for a while? Is switching to separate banks a good idea? Will there be extra steps in setting the banks on the bank loader system in-game or in the organizing process (assigning events to banks, etc)? Currently, we are using a modified script of the FMOD Bank Loader.cs, but it doesn’t stray far from the original, so mostly no big changes to it.
I see, that’s good to hear. Currently, my game uses only 2 streaming assets: music and ambience. Funnily enough, when I enabled “Live Update”, the bug disappeared and only reappeared after turning it off. Details are in here https://qa.fmod.com/t/stuttering-sfx-when-loading-a-scene/24407/6
I also assume preparing to register and download the console API installer on the “Permissions” tab. But I assume this would be for the porting guys ? I just need to prepare the builds and their settings.
As described in the Bank Loading section of our documentation, splitting your metadata and assets into separate banks will double your number of bank files. (Of course, even though you’re loading twice as many bank files, the data being loaded will still be the same, so the amount of time and resources required to load your banks won’t noticably change.)
If you’re using FMODBankLoader.cs, all you need to do is select the bank loader component in the Unity Editor, click the “Add Bank” button to add additional slots for banks, and make sure that both the metadata and sample data versions of a bank are loaded whenever that bank is needed.
You don’t have to worry about the order in which the metadata and sample data banks are loaded, or anything; as long as both are in memory when you try to play an event, it doesn’t matter how and when they got there.
It sounds like Connor has you in good hands. He knows the FMOD for Unity integration well.
That’s right. If you’re working exclusively with Unity and FMOD Studio, and not handling the code side of your port, you are unlikely to need to console API installers.
I see, so I need to reassign 2 banks instead of one for each version of a bank.
I saw that you need to enable “Team visibility” option on the project registration. How would I add the other emails of the porting team to the project in order for them to access the console API installers? What is the usual process?
Team visibility is enabled by default, so you may not need to enable it.
Console permissions are normally company-specific, so if your teammates entered the same company name as you when they created their FMOD.com accounts, they’ll usually be assigned that company’s console permissions automatically.
If a team member entered a different company name for any reason (e.g.: being a contractor who works for multiple companies, having used a personal address to make an account with us before joining your company, making a typo in the form, etc.), that’s not a problem. Just use your own e-mail address to send us a list of their e-mail addresses, and we’ll give them the relevant permissions.
Thank you for the reply!
I see, looks like I have everything I need to start the pre-porting. Thank you for the help. I will send the emails once the porting has started.
!
? I just need to prepare the builds and their settings.