Lag between sound and collision contact

Questions
#1

What can I do to remove the lag between the actual collision contact and playing collision sound?

In my game objects I play a “hit” sound every time the proper collision is triggered. The sound is cropped to start immediately, and right after receiving trigger_response I’m triggering sound.play("#sound") but in game there is an undeniable lag between the hit and the sound :/.

The hitbox collision_object is created via factory when the cursor of the animation is pointing the proper frame. The particlefx accompanying the hit is triggered without such delay :confused:

I use some “sword swing” sound - that is played right before the contact, when the animation of the attack is started and it of course doesn’t end before the end of that animation, but in the middle of it I’m triggering above “hit” sound when the sword is colliding with objects. Can’t those sounds be played in parallel? I have a feeling that the hit sound starts right after the end of animation (which is also the end of the “sword swing” sound) It’s strange because the environment sound is always playing in the background :roll_eyes:

Some paint explanation:

sound_lag
sound_lag.png855×90 3.23 KB

#2

I’m sure you check this but is it possible that hit sound has a blank like fade-in on beginning? (Also if it is ogg you can try it with wav format)

1 Like
#3

Yes, I tried both with ogg and wav :confused: I trimmed it to start immediately:
image

I recorded the problem:

1 Like
#4

That sound lag is way too big. Check your code if maybe the sound.play(’#hit’) is actually called later than the response. A simple print() will do.

1 Like
#5

I moved it above starting particlefx and starting playing “hurt” animation (which is done by a module), the lag is smaller, but still noticable:

if message_id == m.TRIGGER and not self.rotating then
	self.rotating = true
	self.hp = self.hp - 10
	  local sound_t = os.clock()
	  print("Sound", sound_t)
	  sound.play("#impact"..HERO_COMBO)
	  local pfx_t = os.clock()
	  print("Pfx", pfx_t)
	  print("Diff", os.difftime(sound_t, pfx_t))
	particlefx.play("#puff")
	particlefx.set_constant("#puff", "emitter", "tint", color.vec4(color.earth))
	msg.post(HERO_CAM, m.SHAKE, {power = 1, time = 0.4})
    if self.hp <= 0 then
		self.anim:play(anim.DIE)
	else
		self.anim:play(anim.HURT)
	end
 end

Output:

|DEBUG:SCRIPT: Sound|5.493|
|DEBUG:SCRIPT: Pfx|5.493|
|DEBUG:SCRIPT: Diff|0|
#6

Both sound and particles are started via the message system.
So they’ll be processed later in the frame.
And if the particles start at the correct time, then the sound should as well.

Now, it may be that the sound arrives to the sound system in time, but isn’t actually consumed by the sound system until even later. I think we need to look into it.

Would you mind posting a minimal repro case (e.g. with pfx + sound for easy comparison)?

2 Likes
#7

Can you try my OpenAL extension for comparison?

1 Like
#8

I will try to prepare repro and try OpenAl too, though I have a minimal amount of time, so I’ll just notify you :wink: Thanks! :wink:

Even when we use component functions?

#9

Actually sound system with positioned sounds greatly improves the feel of a game, so I encourage you to switch to either OpenAL or FMOD. FMOD is superior, but more complex.

2 Likes
#10

Can OpenAL be combined with Defold’s sound system? Or do I need to create every sound as a source in openal? When I quickly tried to add only one openal source and set hero as a listener, the other sounds (like steps attached to hero.go and played when moving) started to be glitchy.

#11

I thought it could, huh. Turns out not. It could be platform dependant as well.