AudioEcho causes all Roblox audio to violently stutter

We recently released an update using AudioEmitters for the police car sirens in our game. Each vehicle has 4-6 sirens with an AudioEmitter (and wired effects) for each siren. When playing in a live server with 10-20 police cars and an AudioEcho enabled on all sirens, ALL client audio begins to stutter sporadically and some audio becomes inaudible completely. This includes character sounds, legacy sounds, voice chat, etc.

This was not discovered during playtesting and only ended up being an issue in full servers (more vehicles, more sirens) quickly after release. When pulling straws to diagnose the problem, enabling Bypass on all AudioEchos on the sirens immediately resolved the issue.

I’m unsure of the exact factors that reproduce this bug, but my immediate assumption is that it has something to do with the amount of AudioEchos on the client. From my own testing while attempting to fix in the live game, this was present in roughly 90% of joins and there were times where it sounded fine. There were also instances where it would sound fine initially and shortly thereafter begin to stutter. Additionally, this bug was present for most users in-game, but 2-4 players in the same server said their audio was fine at the moment.

This has made AudioEcho unusable in our game.


Game: Emergency Response Liberty County

Notes:

  • This issue would become better/worse sporadically. Audio would be fine for 1-2 seconds and begin stuttering again. In some cases, audio would break completely and nothing was able to be heard.
  • AudioPlayers were created on the server and played on the client.

Audio Instances Used (ordered):

  1. AudioPlayer
  2. AudioReverb
  3. AudioFilter
  4. AudioEcho
  5. AudioChorus
  6. AudioCompressor
  7. AudioLimiter
    → AudioEmitter

AudioEcho Properties (varies slightly):

  • DelayTime = 0.08
  • DryLevel = 0
  • Feedback = 0.15
  • RampTime = 0
  • WetLevel = -16

Videos:


Reports:


A private message is associated with this bug report

Hey @crywink – does this still happen if you set the RampTime larger than 0?

Dug into this a bit more –

When we added AudioEcho.RampTime, it turned the underlying delay into an interpolating-delay. As a result, AudioEcho does more math than it used to, and spends more processing time than it used to.

When there’s an AudioEcho on every single emitter, that can add up – and I think what you’re experiencing here is the entire audio engine missing its deadlines: failing to produce sound in a timely manner, so your speakers intermittently get blanks.

For now, we’ve disabled AudioEcho.RampTime in the client, which should improve your performance; but, if you’re using RampTime to implement the doppler effect, you won’t hear those pitch changes anymore, which isn’t ideal.

There’s a code-change currently in-review to speed up AudioEcho by 2x – once that lands, we’ll try re-enabling RampTime to see if it gives you enough headroom.

1 Like