Since the 2022 LTS was released, I’ve been doing a test upgrade of our project. Our project used to run with a framerate in the hundreds (2021 LTS) but is now in the teens (any 2022 version). Running the profiler, shows that the majority of this is in the Audio.FMODSystemUpdate > Audibility computation.
Our project has a rather large number of AudioSources (2K+) added at startup/runtime from about 400 AudioClips, but very few, if any, are playing at any given time. In fact, I had zero playing and performance was still abysmal. In any case, 2021 was fine…
Does anyone know what changed in the 2022 versions that could cause this? General thoughts/comments welcome as well…
I wasn’t sure if this was actually a bug or something we simply missed, so I wanted to gather more info first.
Found a workaround… disabling all AudioSources then re-enabling them all seems to address our issues, at least initially at startup (I’d expect actually playing a large number of sounds would eventually reduce performance).
It does seem like a bug since simply disabling/enabling AudioSource corrects, will work on another bug report sigh…
Aside from not playing, does anyone know what disabling does?
For those curious, this was categorized as a regression, but “by design”…
Though I’m not sure my report got transcribed correctly between bug report and issue ticket. i.e. you don’t have to be playing any of the sounds to lose performance and various cases that have AudioSources in the same state result in some working and some not…
AudioSources attached/enabled to scene before playing = ok
AudioSources attached/enabled in “Start” = bad
AudioSources attached/enabled in “Start” then toggle disabled/enabled = ok
Regardless of how attached, playing an AudioSource (that completes and doesn’t loop) = incrementally bad (leaks performance)
I ran into this issue in my game too. It’s so weird and it just tank my fps… I don’t understand why they would make such a impactful change in an LTS version?
Can you share a bit more how you made this work? I have tried disable/enable all mine, both gameobject and audiosource component and it have no impact on the performance, the profile keeps telling be it use way to much time on this Fmod audio thingy. Really annoying.
Responding to hear any updates. Very concerning that Unity has pretty much destroyed the audio system for a significant number of users with this (they probably thought innocuous) change. Sigh…
I posted this internally to see if I can gather more feedback on this matter. I’ll let you know what I learn. Just know that we’re doing our best, and that the way all this is intertwined we happen to miss certain side-effects. We do have wide safety net of tests on multiple levels and we catch a lot of these in our process, but not all of them sadly…
Yeah it make sense you need to move the engine forward to make it better, we just need to have a way to follow alone with out rebuilding our entire games.
I’m sure this is not something you are going to rollback, however, if you could provide some alternative way of doing it or a work-around or something, until you get to the part that actually makes this perform good again.
As I remember from the MasterAudio documentation, I’m pretty sure they stated that an inactive AudioSource was almost free, therefore their entire system it build around that assumption, which is apparently no longer the case.
However, I must say, I still see what appears to be a bit random behavior - or else I just haven’t figured out what actually triggers it. Because in my latest build, yes I upgraded to 2022.3.14 and rebuild the Library/cache (just in case) and now I get decent performace with 45.000 AudioSources.
Anyway, looking in the profiler, it’s pretty obvious that this LatePostUpdate.UpdateAudio is the number 1 or 2 most tasking part of my frames, even with no sounds playing at all.
So it seems very odd.
Ugh that’s ugly… I can’t do that myself but I’ll definitely flag it’
It appears that my Danish colleagues are actually onto this and actively working on this! We’re gathering soon to discuss that refactor.
I think you already know it, but for anyone else reading this:
The audio developers of Unity are as much part of this community as you guys are.
I’ve never seen an audio dev working just to pay the bills. We are as frustrated as you are, if not more, when issues like that arise, because we care. We love the depth of the science, understand the weight it has on a game production and admire the effect of well crafted sound design.
Unity Editor/Engine is an incredibly ambitious project considering its scope. Many game developer companies working with other editors/engines are using a myriad of different tools to ship a game, while Unity does embed a lot of that complexity. This means that changing anything in there comes with incredible inertia, and leads to this kind of event.
We’re super grateful when you can surface this kind of workaroundable-but-painful bugs. We’re working on them, and we’ll get them all eventually because we’re proud to work on a product that has such a high impact in a field we love.
The reason that the audibility computations are so slow is that we at some point redesigned the algorithm that computes the audibility of each audio node. The runtime complexity for the new algorithm unfortunately blows up for big graphs with thousands of nodes. We’ve found the root cause for the slow-down and have redesigned the algorithm so that it is much faster (500x speedup for a graph with 3000 nodes).
because we’re proud to work on a product that has such a high impact in a field we love.
