AudioPlayer is debounced when calling :Play()?

Help and Feedback Scripting Support
1

Hi,

I’m currently using the new Audio API, and I’ve noticed some odd behavior with the AudioPlayer instance. When I call :Play() repeatedly in a short timeframe for example, in a UI where a sound should play every time the mouse hovers over a button, the sound sometimes doesn’t play if the hovering happens very rapidly.

Here’s the use case:

  • A hover sound is triggered on MouseEnter for multiple GUI buttons.
  • If I move the mouse over them quickly, the sound only plays intermittently, even though the :Play() method is being called every time.

With the old Sound instance, this behavior worked reliably, the sound played on every hover, no matter how quickly I moved between buttons.

Is this an intentional debounce or limitation of the new AudioPlayer?
And is there a recommended workaround for UI feedback where precise audio timing matters?

Any help is appreciated, thanks.

1 Like
2

This is also a problem with the original sound engine for roblox. I’m not exactly sure what causes it exactly since I’m no engine nerd, but its probably that the engine for whatever reason can’t handle rapidly playing the same sound instance over and over again.

I’ve found that creating a new instance and then playing it works far better with no pausing issues.

function playSound(sound)
    local clone = sound:Clone()
    clone.Parent = sound.Parent
    clone:Play()
    game:GetService("Debris"):AddItem(clone, sound.TimeLength)
end
3

Wouldn’t this be bad for performance though? Right now I’m caching frequently used audio such as ui hover and ui click so that I don’t have to create a new AudioPlayer each time I use it.

4

The debounce is really annoying. The best way I’ve found to go around this is doing:

local function playSound()

	if audioPlayer.IsPlaying then
        audioPlayer:Stop()
    end

    audioPlayer.TimePosition = 0
	audioPlayer:Play()
end
5

Yeah, of course you’d need to create a new audio player, but NOT a new audio emitter/audio output device. It shouldn’t impact performance all that much, I know for a fact that it doesn’t lower framerates at all considering that my shooter is still perfectly capable of 400+ FPS using that method of playing audio, even for extended sessions.

Although, I’d argue the old sound instances are more than good enough for UI elements, the only positives to the new API are when they’re in 3D space imo.

also FYI, I tried this myself originally to fix the same issue on my game and the same problem would happen, albeit less frequently.

If you want to completely remove the problem, my method fixes it entirely. If just mitigating it is fine, then this method is probably more optimal.

1 Like
6

Is there any performance difference between adding the audio to debris or making a .Ended connection?

game:GetService("Debris"):AddItem(AudioPlayer, AudioPlayer.TimeLength)

Compared to:

AudioPlayer.Ended:Connect(function()
   AudioPlayer:Destroy()
end)
7

Yeah, the connection stays if you don’t call Disconnect, so that’d cause a memory leak.

8

Calling Destroy() on any created instance will disconnect all of its connections automatically

1 Like