0
0

I’m trying to use the Spawn function to trigger engine spark sounds. I have a sound definition with 20 sounds. All are mono 16 bit, 50 ms long.

Here’s the first problem:

When I set the min/max spawn time to 50 ms each, and the Max Spawned Sounds to 1, I would expect the files to play back every 50 ms with no variation. However, when I recorded the output and looked at the waveforms, I found something quite different. The sounds were being triggered in a range from 105 ms to 128 ms. In other words, slower than the 50 ms specified, as well as not spawning at a consistent rate. I repeated this with settings of 25 ms and 100 ms, and got similar results. The sounds were always played back at a slower rate, with inconsistent timing. What I also noticed was that the timing of the playback seemed to depend on the individual files. For example, every time file X would play, it would take 128 ms until the next file. Every time file Y would play, it would take 105 ms until the next etc. This would be normal behaviour if FMOD was waiting for a file to finish before going on to the next, but remember these files are all 50 ms long. Another strange thing was that when I changed the Maximum Spawned sounds from 1 to 2, the frequency of playback doubled. This is strange because the sounds are all 50 ms long, so with a minimum spawn time set to 50 ms or higher, the maximum number should have no effect.

The second problem I had was when I ran this event in the game (PC). The sounds are all in their own wave bank. When I set the bank type to either load or decompress into memory, with either PCM or MP3 compression, the sounds play back in the game even slower than in FMOD, as well as being pitched down. This only happens to the sounds in this event. All other sounds play back fine. The only way I could get the event to sound the same in the game was to set the bank type to Stream From Disc. However, there are two problems with this: In the game the sounds start off ok, but tend to "choke" after a bit, fewer sounds get played. This is probably because it’s using a lot of CPU power to stream all these tiny files so quickly. Also, in FMOD designer with the bank type set to stream from disc, the sounds are being double triggered, so they sound like a cheap flanger/doubler effect is being used on them.

Anyone have any idea what’s going on here? Am I pushing the limits of FMOD by trying to play back such small files so quickly?

  • You must to post comments
0
0

Hi, this does sound like odd behaviour. It would be very helpful to see your project and audio assets; could you send a small FDP that demonstrates the problem (include the wave files) to support@fmod.org?

One thing worth mentioning is that the spawn behaviour is implemented in EventSystem::update(), so its accuracy will be affected by how frequently you call EventSystem::update(). How frequently are you calling EventSystem::update()? Have you tested your project in the Event Player utility that ships with FMOD Designer?

Thanks,
Ben

  • You must to post comments
0
0

Thanks for the reply. I sent an FDP file with the wav files. I’ll have to ask my programmer how often we’re doing the event call.

  • You must to post comments
0
0

Thanks for that, I’ve had a look and I think I can see what the problem is.

Note that I didn’t observe any correlation between the specific file and the spawn period; all the files I tested gave periods between 106 and 130 milliseconds.

The issue is that the spawn timer (which determines when to spawn a new sound) is reset whenever it reaches 0 [b:k2l139a8]regardless of whether a sound is spawned[/b:k2l139a8]. This means that if "Maximum spawned sounds" (max spawns) is 1, and the previously spawned sound is still playing, the system will wait another 50 ms before trying to spawn another sound.

The process goes something like this:
[list=1:k2l139a8]
[:k2l139a8]Spawn a sound[/:m:k2l139a8]
[:k2l139a8]Wait 50 ms[/:m:k2l139a8]
[:k2l139a8]Attempt to spawn a sound, but fail because the previous sound is still playing[/:m:k2l139a8]
[:k2l139a8]Wait 50 ms[/:m:k2l139a8]
[:k2l139a8]Spawn a sound[/:m:k2l139a8][/list:o:k2l139a8]

We intend to fix this issue in a future release, but for now you can work around it by increasing the max spawns value to 2, so that step 3 above doesn’t fail. This would change the above sequence to:
[list=1:k2l139a8]
[:k2l139a8]Spawn a sound in slot 1[/:m:k2l139a8]
[:k2l139a8]Wait 50 ms[/:m:k2l139a8]
[:k2l139a8]Spawn a sound in slot 2[/:m:k2l139a8]
[:k2l139a8]Wait 50 ms[/:m:k2l139a8]
[:k2l139a8]Spawn a sound in slot 1[/:m:k2l139a8][/list:o:k2l139a8]

I noticed that the project you sent me had a spawn intensity effect; if the spawn intensity can go above 1, you may need a higher max spawns value (e.g. if spawn intensity is 2, the system will attempt to spawn a sound every 25 ms, so you would probably need to set max spawns to 3).

Note that because spawning is done inside the EventSystem::update function, the accuracy is reduced to multiples of the time between EventSystem::update calls. This will make your engine sound somewhat irregular.

[quote="JHedges":k2l139a8]Am I pushing the limits of FMOD by trying to play back such small files so quickly?[/quote:k2l139a8]

Yes, you are a bit :-)
We are intending to improve spawning accuracy in a future release using new features of the low-level API, but for now events with very short spawn times will sound irregular.

Ben

  • You must to post comments
0
0

Thanks for looking into this. Your explanation makes perfect sense, and would be what I would expect IF the files were more than 50 ms. They’re not though. I still don’t understand why step 3 is failing. The files are all 50 ms, so the spawn counter shouldn’t be waiting. Even when I set the spawn time to 100 ms, the same thing happens, it just waits longer, and takes much longer than 100 ms before triggering the next sample.

As far as pushing the limits goes, I don’t mind it being a bit irregular in it’s playback. That’s actually a desirable thing when it comes to engine sparks. I just don’t want to bring the game’s framerate to it’s knees!

  • You must to post comments
0
0

Yes, you’re right. My unspoken assumption in my previous post was that inaccuracies in the sound playback code were causing step 3 to fail (i.e. the sound was taking slightly longer than 50 ms to finish playing back, causing the spawn timer to be reset).

However, testing with a spawn time of 100 ms as per your example reveals that there is a bug in our code which stops the spawn timer from counting down if the number of sounds playing is equal to the max spawns value. This means that when max spawns is set to 1, the spawn time is actually controlling the time from the end of one sound to the start of the next, rather than from the start of one sound to the start of the next.

The logic looks like this (when spawn time = 100 ms):
[list=1:8qzs382t]
[:8qzs382t]Spawn a sound[/:m:8qzs382t]
[:8qzs382t]Wait for the sound to end[/:m:8qzs382t]
[:8qzs382t]Wait 100 ms[/:m:8qzs382t]
[:8qzs382t]Spawn a sound[/:m:8qzs382t]
[:8qzs382t]Wait for the sound to end[/:m:8qzs382t]
[:8qzs382t]Wait 100 ms[/:m:8qzs382t]
[:8qzs382t]…[/:m:8qzs382t][/list:o:8qzs382t]

This has been fixed for our next development release (version 4.15.04), which should be out at the end of the week. What branch are you using? We’d prefer not to change this in the stable branch, as people might be depending on the old behaviour.

Ben

  • You must to post comments
0
0

Ok, that makes sense now. Don’t worry about changing a stable branch. I assume I can just increase the Maximum Spawned Sounds and get the same behaviour in future versions.

I’m still concerned about it playing back slower and lower in pitch when it runs in the game. I haven’t heard back from my programmer about how often he’s calling EventSystem::update(). Would that be the reason, or could it also have to do with this bug?

Thanks for the help.

  • You must to post comments
0
0

[quote="JHedges":3imv67c7]I’m still concerned about it playing back slower and lower in pitch when it runs in the game. I haven’t heard back from my programmer about how often he’s calling EventSystem::update(). Would that be the reason, or could it also have to do with this bug?
[/quote:3imv67c7]

The spawn rate accuracy will depend on how often EventSystem::update() is called, but it shouldn’t affect the pitch.

[quote="JHedges":3imv67c7]When I set the bank type to either load or decompress into memory, with either PCM or MP3 compression, the sounds play back in the game even slower than in FMOD, as well as being pitched down.
[/quote:3imv67c7]

Testing in Event Player, I can’t reproduce the sounds being spawned slower; it might be linked to your EventSystem::update() frequency, as mentioned above.

I can reproduce the pitch down effect, but only for lossy compression formats (e.g. MP3) – if I set the bank to use PCM, it sounds the same as it does in Designer. This is caused by FMOD’s seamless MP3 loop encoding; it stretches small sounds to fit in an MP3 frame in order to provide seamless looping. We are aware of this issue and it will be fixed in the next few weeks.

Are you sure the sounds are being pitched down when the wavebank is set to PCM? Have you observed this effect in Event Player?

Ben

  • You must to post comments
0
0

Heard back from my programmer.

We’re running EventSystem::update(), 125 milliseconds

Should we bump that up?

  • You must to post comments
0
0

Replying to this to say the next version of designer (today or tommorow) will fix a problem with the encoder stretching short samples that don’t loop, so the pitch may sound wrong on these type of sounds.

  • You must to post comments
Showing 9 results
Your Answer

Please first to submit.