Upon uplifting to the new Audio API in my game, I noticed that when a lot of AudioPlayer objects exist in the game (1000+), nearly every time a Sound (not an AudioPlayer) object finished playing there was a significant spike in the microprofiler under the Sound task.
I thought this may be a bug so I created a reproduction place which clones up to 5000 AudioPlayers into workspace, these AudioPlayers share 10 different asset ids. They are not wired to anything, they’re just parented in workspace, not even being played. I clone these on a loop running every frame until 5000 clones have been generated, when first starting the place the performance impact is minimal, but as the number of AudioPlayers approaches 5000 (again, unwired, just chilling in ReplicatedFirst) the Sound task in the microprofiler climbs up to about 30ms on my PC every time I stop moving my character (example of an old Sound object playing).
Not sure if the intention is that you go all in on the new API, but I noticed the same issue does not exist when a new AudioPlayer object finishes playing (audible or not).
System information:
CPU: Intel i7-13700F
GPU: RTX 4080
RAM: 64GB DDR5-5600MHz
OS: Windows 11
Run the place, and move your character in short bursts while observing the microprofiler, over about 30 seconds you’ll notice large spikes in the Sound task as your character’s default sounds stop playing. If you walk for a second or two and then stop walking, once the walking sound stops you’ll observe a large spike in the microprofiler.
Hey @CompilerError – since Sound & AudioPlayer are built on the same underlying audio engine, it’s possible for slowdowns in one to affect the other. I’m able to reproduce this – I think the long Sound task is moreso a symptom of the extremely long FMOD::Output::mix
Will check it out – perhaps the audio engine is still doing some work for all those silent AudioPlayers, and that adds up when you get 5000 of them. With any luck it’ll be a simple bug.
AudioEmitters have a similar issue, even if they’re not wired or playing any sounds, if you have a lot of them they take up computing time on the microprofiler
this is our game where we discovered the issue: No Man’s Land
in No Man’s Land the Sound time spikes to up to 12ms per frame on my system, reaching higher numbers on lower end devices
Hey @iOwn_You – the reason for that is slightly different
Each AudioEmitterxAudioListener pair does some panning & distance attenuation work per-frame to make sure any audio that starts streaming into that AudioEmitter is heard coming from the proper 3d location. We do that work regardless of whether or not something is wired-up right-this-second, because something could get wired up at any moment
There are some optimizations in progress to make many-emitters faster (parallelizing the per-frame updates, or implementing a “sleep system” for emitters that have no input, similar to what physics does) but the 5000-AudioPlayers issue was just a bug, nothing fancy
I see, thanks for the response
a sleep kind of system would be great, the reason we have so many is because we cache them for later use so we dont have to create new instances so frequently, but we will try doing that instead for audio emitters until then.
Is Instance creation a bottleneck in your experience? If it is, we should really strive to make that faster, since creating/destroying instances is expected to be a super common operation
I actively go out of my way to create/destroy as infrequently as possible as it tends to be a very slow operation. This is not specific to sounds, but in the case of sounds I found this issue because I “cache” sounds to avoid creation/deletion since next to allocating the FMOD channel (please please please improve the performance here if possible ) it is the slowest thing you can do with sounds. When you combine instancing a sound and playing it at the same time it tends to be very wasteful. It really holds the engine back on mobile IMO. We have to do a lot of weird stuff in order to avoid losing 60 FPS on a flagship Android phone in a prototype game with highly simplified details.
For example, we want to play footstep sounds in a particular position at a particular time and we may want to throw some Foley sounds in with it… Often times playing two sounds at once can take nearly half a ms on my PC, my phone can be much worse. I should probably log a new post about this though. I would be curious about engine limitations here. I know nothing at all about FMOD, but perhaps there are some best practices around this issue. I’ve tried just setting their playback speed to 0 and starting/stopping sounds using that and their time position, but that ends up pretty quickly utilizing all available channels.
Creating instances generally seems to be a pretty slow process, but that was always the case for any instance.
we use a module to create instances when the server starts and store them for later use and recycle them, it proved to have a performance benefit for us (with the exceptions of sounds due to the issue i described in the earlier post)
there’s also this public module that seems to be pretty popular to address the same issue
)
