So I have been receiving the
" [FMOD] AsyncCommandBuffer::growBuffer : Growing command buffer to 65536 bytes." warning,
and thought it was a little strange. I’m currently in a scene where many sounds play, but not that many sounds play, so I was wondering why it changed that. I looked at other posts concerning this and it said to lower the max instances, but right now i have all my instances for each object playing between 1-3, so I’m not sure why it does that.
I became confused as I don’t believe the amount of active and playing sounds are that much.
I also noticed a few other things, for example:
I have 8 drying machines with a max instance of 3. It says here they are playing and active, but I am not even near any of them at the moment.
Is there a way to not have the sound play at all if I’m not near?
Also, I am using a series of bubbles to create audio ambience at a lake, and using a transmitter:
However, even with setting a max instance of 4, it still is technically playing all 23 instances? I think?
The memory usage throughout is always kept under 16k KB, so it’s not using a lot of memory.
If I had to TLDR, my questions are:
Why am I receiving the growBuffer warning when I am not using that many sounds? Is it a big deal that it does this?
Why are ambient sounds like the drying machine are playing even when I am not in audible distance? Is there any way to prevent this to save space?
Are the sounds at the lake using transmission not set up correctly if, even though only 4 are active, all of them are playing? Is that a problem for memory?
Thanks, I hope this was enough detail. Let me know if there’s any more info I can give you.
Best,
John
This warning is telling you that the studio system is receiving more commands than it can currently keep track of. As a result, it is having to expand the command buffer to keep track of everything. That is the growBuffer warning.
While 53 total events is not a large amount they all could be calling into the Studio system which could be a cause of the warning.
In the profiler, I would suggest having a look at the API Calls View (FMOD Studio | Profiling - API Calls View) which you can use to check how many Studio calls are being made each frame.
An option is the Stop Events Outside Max Distance option in the FMOD Integration settings
This will stop sounds once they are out of their maximum distance, keep in mind they will have to be restarted if you want them to be heard again.
An alternative option is setting the Max Instances on the Master Bus and setting Stealing to Furthest. This will limit the maximum instances that can be played in total but does solve the issue of having to replay events once coming back into range.
When you mention “However, even with setting a max instance of 4” is this on the Transiciver event or on the Reciever event? If there is only one Transceiver event with the limitation and lots of Reciever events that limit will never be hit.
Hi Connor, thanks for your reply, I’m looking at the API log, does this mean that each of these lines is a separate sound being called in the game? I don’t even have these many sounds made for it yet haha. That’s worrying?
For the dryer and stopping sounds, will performance take a huge hit from having those sounds playing in the background?
There are currently 4 dryer sounds with this result in performance:
Probably would like to have 7 in total, scattered around the level.
And this same process would be for all background devices, like washing machine, fridge hum, microwave whir, etc, looping in the background.
I can do the restart of it is better in the long-run though, if you think?
No, this is just the list of commands being sent to the FMOD system in a single frame. This may indicate that some code is not behaving as expected. Looking at the calls it seems that a lot of events are being moved in the scene, is that correct?
That will depend on some factors if there are only 4 it shouldn’t be too expensive. However, since they are out of earshot we should be trying to virtualize them or stop them to save on resources. As things expand like so:
This is when things will start to get more expensive. So getting these optimizations going early is a good idea.
In regards to your Transciever if there is only one in the scene it shouldn’t need the max instances set, and I would suggest setting its priority to Highest to make sure that it does not get virtualized ever, priorities are further explained
under FMOD Studio | Event Macros Drawer Reference - Priority. The Receiver also seems to be set correctly and in your profiler session, you can see that only 4 events are Active which is what you’d expect to see.
Blockquote
No, this is just the list of commands being sent to the FMOD system in a single frame. This may indicate that some code is not behaving as expected. Looking at the calls it seems that a lot of events are being moved in the scene, is that correct?
Yes, there are a lot of moving, physics-based items with sounds or sound scripts attached to them. So this amount of commands being sent is normal?
Is this what is causing the growbuffer warning?
Blockquote
This is when things will start to get more expensive. So getting these optimizations going early is a good idea.
So I will set these to low or lowest priority then, I imagine?
Blockquote
In regards to your Transciever if there is only one in the scene it shouldn’t need the max instances set, and I would suggest setting its priority to Highest to make sure that it does not get virtualized ever, priorities are further explained
Okay, I will try setting the transceiver to highest.
The warning tells us that maybe there are some events/behavior that may not be behaving as expected. Would it be possible to get the Unity project uploaded to your profile so I can check it on my side? You will have to register a project with us to be able to upload the project.
Not necessarily, but more looking into limiting the event instances or limiting the instance that are allowed in the group bus.
It is currently pending approval and then I will upload the project.
I am not very familiar with the group bus system, what is the difference between using max instances in the group or max instances on the individual event? If I have one column for all SFX, isn’t there the chance that it will cut off a sound I need because there’s no specification?
I will link to our Group Bus documentation, FMOD Studio | Mixing - Group Buses and Routing, which goes into further detail about how to use the bus instances limiting, FMOD Studio | Mixing - Bus Instance Limiting. In summary, it allows control over large groups of events that can be broken down into categories e.g. SFX, Music, and UI which can then be further broken down to allow for finer control. I would suggest creating overreaching group buses that do not have limits but then creating smaller buses in which you will then place the limits e.g. House appliances.
I would pick up and throw items (with right click) and continue this action repeatedly while walking towards the lake. For me that usually produced the action consistently.
Unfortunately, I was still unable to reproduce the issue.
Could I get you to run DxDiag: Open and run DxDiag.exe - Microsoft Support. There may be some differences in our machines which is causing the differences in behavior. Please upload the results to your profile.
An option may be manually expanding the size of the command buffer. This will increase the initial memory that FMOD uses but should stop the expand command from being called. This can be done in the RuntimeManger.cs on line 326. More information about the Advanced Settings can be found here: FMOD API | Studio API Reference - FMOD_STUDIO_ADVACNED_SETTINGS.
Another warning I was encountering was Loading delay exceeded, sound may play at incorrect time which I was able to solve by enabling the Load Bank Sample Data option in the FMOD Integration settings: Unity Integration | Settings - Load Bank Sample Data.
In terms of not reproducing the issue, are you picking up and throwing items as you walk along? By the time I throw about 10 items (and a lot of boulders) AND have walked past the fountain AND have walked past the lake (that sounds like a lot but it’s about 20 seconds) then the warning pops up.
The first change was the correct one to make, apologies, I was not clearer. You can keep increasing the initial buffer size till you are no longer seeing the error.
I followed the detailed steps and let the game fun for 20 mins and I still did not see the error.
Sorry for all this mess, I hope this isn’t taking up too much time.
I set the commandqueue to 120,000 and, while it did pop up later, it still popped up, that it was growing the command buffer to 65536. Is this just something that I need to let happen? Will it affect the game on building?
It is just a warning letting you know that the command buffer is growing thus taking up more memory. It should not affect the game in any noticeable way.
Could you please try the size to 131,072 rather than 120,000 as this isn’t a value that the ADVANCEDSETTINGS can use. This is shown as the buffer was ‘expanded’ to a smaller value than you set.
I added 1 to each of the numbers you gave me as my script has the extra line from adding the changed buffer size. When these three lines are commented out, I get this:
Apologies, it seems your lines do not line up with mine. Looking at your previous posts, you will have to comment out 324325 and 330. Hopefully, this will solve it. Again, apologies for all the confusion.
