Acoustic simulation causes severe performance regression

When enabled, audio acoustic simulation appears to severely degrade the performance of AudioEmitters in my game, cutting my framerates by three quarters, from 120 to 30.

I have only 7 audio emitters.

Video on Streamable.

A private message is associated with this bug report

3 Likes

Hey @ThoughtSpinnr – I opened the place and am able to reproduce the lag. Will investigate

1 Like

so i WASNT going insane. i was looking through the acoustic simulation post and didnt see anything about lag

Thanks a bunch! This was a very confusing issue for me to narrow down – for weeks I’d been thinking it was the fault of a private beta I’ve been helping test.

No this is definitely our bug

There’s a fix-candidate in-review that should go out in a couple weeks; in my testing, this is the before & after comparison in your placefile:



And if I disable the emitters the framerate is pretty much the same:

3 Likes

This looks much better, thank you! What ended up being the culprit here?

Sort of two root causes

Acoustic simulation uses physics queries under the hood; the most common one checks how dense the parts within a region are. Since this placefile uses MeshParts that are fairly close together, that ended up being slow – both because it has to scan more parts, and the parts themselves aren’t simple convex shapes. So one fix is to make that density-in-region query faster (but more approximate). This could also be made faster by using simpler Parts or toggling some of the meshes to AudioCanCollide = false

The other thing is that we’re doing these queries asynchronously on background threads, but updating the physics data structures on a foreground thread. Those background threads need to coordinate with the foreground thread so that there isn’t a data-race/crash. That coordination mechanism was giving equal priority to all threads – but in this case we need the foreground thread to “always win”, because it impacts the framerate

1 Like

Ah, gotcha. Thanks very much for the explanation! :smiley:

I suppose this means that in extreme cases like mine, occluded audio may take a little longer to update in order to never harm the framerate?

Yeah; the framerate will be fine, but the acoustics might be a few frames behind schedule

1 Like