This sounds great! Can’t wait to see how this goes.
Does this feature, and having AudioCanCollide on, degrade performance? My game likely doesn’t benefit much from this, and uses a lot of parts, so if this audio collision being on has performance impact I will need to know please.
1 Like
You will always be able to disable it. Normally betas get forced onto us but this one will be a toggle. There may be a performance drop but if it hinders your game’s performance too much you can disable it when it comes out.
Well I’m trying to figure out if it does or not preemptively to know if I should disable it or not, since it’d be easier to so sooner than later, so I’d love it if a staff member could provide some information on it performance
1 Like
I’m really glad to see acoustic simulation coming to Roblox. However, I share some of the concerns raised here. Many mobile devices simply can’t handle realtime acoustic simulation without major compromises in performance or sound quality. This can become a real balancing issue for competitive games where acoustics play a meaningful role in gameplay, because different players may end up experiencing different simulations. And of course, realtime simulation will affect 100% of mobile players through faster battery drain and potential throttling. Introducing a purely cosmetic feature that adds even a few percent of CPU load is fundamentally flawed. If every new gimmick carried that cost, we’d quickly hit the ceiling of modern smartphone capabilities.
That’s why I don’t understand why we didn’t get baking support. It’s obvious we need a more flexible, hybrid system where developers can manually bake probes and disable realtime simulation when needed. Just look at the top Roblox experiences — most of them are static enough that realtime simulation simply isn’t worth the performance cost we’re seeing in current tests. Characters and small movable objects can typically be ignored without any noticeable loss in acoustic realism. These games could achieve maximum quality at near-zero CPU cost simply by relying on baked probes. But right now, you’re putting developers in a position where they have to sacrifice stability and risk a drop in player retention, which remains the sacred cow of the free-to-play model. And in the end, this will likely lead to yet another unused, abandoned feature. That’s sad.
1 Like
now devs and new games will use it new feature least of just be lazy to make it
This afternoon, I was debugging some frame drops caused by my camera controller and eventually traced the issue to Acoustics being enabled.
According to the profiler, the performance hit was coming from the calculateParameters function under the Acoustics group. It’s likely something they’re still optimizing, but the impact is definitely noticeable—for now, I’ve had to disable it.
Acoustics Enabled:
Acoustics Disabled:
4 Likes
this is pretty cool, and I think the reverberation is quite good but I can’t say the same about the occlusion. does the occlusion algorithm only account for one single sound ray? (that is, directly from the source to the listener)
because if that is the case, then it explains why the occlusion is extremely strange. should note that sound enters our ears from multiple different directions and all the sound waves are essentially averaged out
1 Like
So far the acoustic simulations have been pretty rough unfortunately. Open area performance sounds wholey innacurate and more like a cathedral or larger interior space instead of a dry open field with super minimal reverb (Reaching max raycast distance and determining it’s a large interior space?). Standing close to a singular wall would sound like a closed in studio even when outside.
The ability to bake more accurate reverb probes for spaces would be a really good feature as pushing the limits with visuals and audio doesn’t leave much room for realtime simulation in most cases.
Improvements to the occlusion logic when in regards to point sounds or the ability to select which processes you want simulated in realtime would be lovely.
Overall great bones, but definitely needs more time in the oven.
3 Likes
Praying that it won’t cause any performance issues.
This feature is too nice to not be used.
1 Like
too late. alr causes performance issues
3 Likes
Is it ok to make it backwards compatable? I don’t like to use the new Audio API as it is complicated to use. I usually use the classic, however old Sound instance.
3 Likes
I’ve been waiting for this feature for such a long time, and now there it is. This is another big step towards realism in Roblox games.
1 Like
I believe it would be nice to have SimulationFidelity property be more customizable by having seperate options, like to toggle muffling only or toggling sound pathfinding only, for example some use cases might want to only have the sound muffled behind objects rather than wrap around corners.
I’m not sure why they disabled it but I probably could come up with a theory. When GetSpectrum first released I made a Karaoke game, but ever since they disabled it the game can’t really be played. I also was working on a spirit box for a phasmophobia type game, where if you spoke it would understand what you said and do responses. They probably disabled because you could save people conversations by saving their frequencies and converting to a wav file, which basically is stalking them.
1 Like
This beta appears to be causing very noticeable Frame Lag whenever a sound (AudioPlayer) is created/played.
Here’s an example of the performance without the Beta:
Here is an example with the Beta Enabled, notice the slight stuttering and jumps in the MicroProfiler:
The Client Script Profiler tells me the performance bug is originating within this chunk of code. Again, the spike in Script Usage (40%) only occurs when Acoustic Simulation is enabled.
function module.connectAndPlay(sound,object,doGlobal)
local wire = Instance.new("Wire")
wire.Parent = object
wire.SourceInstance = sound
local emitter
if doGlobal then
wire.TargetInstance = game.SoundService.AudioDeviceOutput
else
emitter = Instance.new("AudioEmitter", object)
wire.TargetInstance = emitter
game.Debris:AddItem(emitter,30)
end
sound:Play()
local con
local con2
local function cleanup()
con:Disconnect()
con2:Disconnect()
if sound and sound.Parent then sound:Destroy() end
if emitter and emitter.Parent then emitter:Destroy() end
if wire and wire.Parent then wire:Destroy() end
end
con = sound:GetPropertyChangedSignal("Parent"):Connect(function()
if not (sound and sound.Parent) then
cleanup()
end
end)
con2 = sound.Ended:Connect(function()
cleanup()
end)
end
Another thing to note is that the lag and stuttering tends to only happen when either you or the Audio Source is moving (continuously changing relative position).
2 Likes