0
0

Our units play footsteps when they walk (like every game on the planet) and I’m trying to figure out why some of the footstep sounds aren’t playing.

Here’s some data:

We are using the FMOD event system.

The sound playback is driven by the animation system. So for this test a walk, the unit took 11 steps. There are two wav’s that are defined in the footstep sound definition and both are less then a second long.

The footstep event has Max Playbacks set to 100 (I’ve tried all sorts of values here with little difference).

Here is some log data:

[code:3jzg1f5v]
<Default> [Audio] – 1/23/2007 18:14:39:311000 PM – Starting sound cue #1 at 65679311 (Plays)
<Default> [Audio] – 1/23/2007 18:14:39:717000 PM – Starting sound cue #2 at 65679717 – 406 ms since previous (Plays)
<Default> [Audio] – 1/23/2007 18:14:40:108000 PM – Starting sound cue #3 at 65680108 – 391 ms since previous (Doesnt play)
<Default> [Audio] – 1/23/2007 18:14:40:514000 PM – Starting sound cue #4 at 65680514 – 406 ms since previous (Doesnt play)
<Default> [Audio] – 1/23/2007 18:14:40:920000 PM – Starting sound cue #5 at 65680920 – 406 ms since previous (Plays)
<Default> [Audio] – 1/23/2007 18:14:41:310000 PM – Starting sound cue #6 at 65681310 – 390 ms since previous (Plays)
<Default> [Audio] – 1/23/2007 18:14:41:716000 PM – Starting sound cue #7 at 65681716 – 406 ms since previous (Doesnt play)
<Default> [Audio] – 1/23/2007 18:14:42:122000 PM – Starting sound cue #8 at 65682122 – 406 ms since previous (Doesnt play)
<Default> [Audio] – 1/23/2007 18:14:42:512000 PM – Starting sound cue #9 at 65682512 – 390 ms since previous (Plays)
<Default> [Audio] – 1/23/2007 18:14:42:918000 PM – Starting sound cue #10 at 65682918 – 406 ms since previous (Plays)
<Default> [Audio] – 1/23/2007 18:14:43:309000 PM – Starting sound cue #11 at 65683309 – 391 ms since previous (Doesnt play)
[/code:3jzg1f5v]

For some reason not every sound plays and I haven’t figured out why. Any insight into what I might be doing wrong either in code or in the FMod designer?

Update:

I’ve looked into this a bit further and it looks like for this particular case that getGroup() and getEvent() get called twice for the same event string. The values returned are different and I want to make sure this is expected. Are we using FMOD incorrectly? Should we only be calling these two functions once per unique event?

I’ve also tried calling getEvent on a group and getEvent on the event system object and they both act identical. I imagine they are supposed to act the same way, but I still haven’t figured out why some of the sound events fail to play.

I’ve tried removing one of the sounds in the definition so it doesn’t randomly choose one to play, but that didnt make any difference either.

Update2:

Just noticed that you guys fixed some bugs in the designer tool that sound very close to what I’m experiencing:

[code:3jzg1f5v]

23/01/07 1.7.1

  • Fixed "Max playbacks" so it can’t go -ve

22/01/07 1.7.0

  • Fixed "Max Playbacks Behaviour" writing out wrong value and causing wrong getEvent behaviour in runtime engine.[/code:3jzg1f5v]

Upgrading to check and see if that fixes it.

Update 3:

Unfortunately this didn’t help at all. Anybody?

Thanks in advance!

  • You must to post comments
0
0

For a start you can reduce your max playbacks value from 100 to something more reasonable. Max playbacks is the number of instances of this event that can be played back simultaneously – 100 footsteps playing all at once would sound like a big mess. Think about how many footsteps the player really needs to hear at once – or even how many the player could actually distinguish between before it just sounds like "many" footsteps. I’d be looking at something well under 10 probably.

Call getGroup as many times as you like. Each time you call getEvent it returns a reference counted event instance handle – the reference counting is what causes the returned value to be different from subsequent calls to getEvent – this is normal. Calling getEvent on your footsteps event each time you want to play it is reasonable usage.

Does FMOD return any errors when you try to play the event? How many are you trying to play at once? Can you reproduce the error behaviour outside of your game? Ideally we could use a small repro case to reproduce it on our end but, failing that, send us your .fdp and I’ll see if anything looks amiss.

Cheers,

  • You must to post comments
0
0

[quote:1qvb0rfb]For a start you can reduce your max playbacks value from 100 to something more reasonable. Max playbacks is the number of instances of this event that can be played back simultaneously – 100 footsteps playing all at once would sound like a big mess. Think about how many footsteps the player really needs to hear at once – or even how many the player could actually distinguish between before it just sounds like "many" footsteps. I’d be looking at something well under 10 probably. [/quote:1qvb0rfb]

Agreed. This adjusting to 100 was a sanity check.

[quote:1qvb0rfb]Call getGroup as many times as you like. Each time you call getEvent it returns a reference counted event instance handle – the reference counting is what causes the returned value to be different from subsequent calls to getEvent – this is normal. Calling getEvent on your footsteps event each time you want to play it is reasonable usage. [/quote:1qvb0rfb]

getEvent is actually only called twice for this particular animation since the feet of the unit only strike the ground twice. The calls to getEvent occur when the animation is loading which is way before the animation and sounds play.

FMOD doesn’t return any errors. From my debug output in my previous post, you can see that we’re not trying to call very many at once. We’re calling Event::Start() roughly every 406 ms.

[quote:1qvb0rfb]Can you reproduce the error behaviour outside of your game? Ideally we could use a small repro case to reproduce it on our end but, failing that, send us your .fdp and I’ll see if anything looks amiss.[/quote:1qvb0rfb]

I will go ahead and send you my .fdp in the morning and start modifying an example app to try and emulate this behavior.

  • You must to post comments
0
0

Ok, after hearing that the handles returned from GetEvent are instances, the light bulb finally went off in my head 😉

We were only calling GetEvent() twice for the walk animation. So what was happening is that when the third step hit the ground (and we were about to play another footstep sound RE-USING one of the event instance handles), the state returned from Event::GetState() was equal to EVENT_STATE_PLAYING | EVENT_STATE_CHANNELSACTIVE.

It now works as intended after changing the code to preload the event data during level load and call GetEvent() right before each call to Event::Start().

Thanks for the info!

  • You must to post comments
0
0

Good to hear.

  • You must to post comments
Showing 4 results
Your Answer

Please first to submit.