I’m working on a sound for a weapon that has a cadence of 3 bullets per shot.
My first approach was to create an event with 3 sound definition instances that have a length of the given cadence (66 ms) and a velocity parameter (set to 1). The sound definition contains various wavs that are chosen randomly and a little pitch variation. I also added a sound definition for the gun echo.
This is shown in the following image:
This should play 3 sounds, one each 66 ms and then the echo, right?
The thing is that the sound isn’t constant. Not even when played in the FMOD designer. When measuring the time that the actual sound starts (FMOD_EVENT_CALLBACKTYPE_SOUNDDEF_START) we have variations that range from 64 to 74 ms, when it should be 66 or quite close. When the difference between sounddefs is 6 ms or greater, the inconsistency is quite noticeable.
We could use a single wav file with the 3 shots in it, but I’d like to have a per-bullet subtle sound variation. I’ve tried reduccing the DSP buffer size to reduce latency and also tried updating FMOD from a different thread (just to make sure this wasn’t due not calling EventSystem::update at the right rate).
Is there something I can do to make sure the 3 sounds are played at a constant rate? There may be something I’m missing or doing wrong and I’d appreciate if someone could point me in the right direction.
- janko asked 7 years ago
Thanks A LOT for the response. That idea helped a lot. We were using al older version of Designer, so we didn’t have this ‘Spawn count’ feature. It’s worth the update, though
Actually I used a little variation of this idea. Since our waveforms are not exactly 66 ms long, I set ‘Spawn Time’ to [66,66] and ‘Maximum spawned sounds’ to 3.
This worked way much better that our previous solutions. Still, the sound spacing suffers when serious fps drops occur, especially in older machines. But it happens much less often than before and I guess it’s normal under low frame rate conditions.
Calling Eventsystem::update from a different thread (race conditions taken into account) helps to alleviate this, but I understand this is not recommended, so we’ll have to look into making the fps stable (or going back to the one waveform solution).
- janko answered 7 years ago
[quote:39ml5cud]we have variations that range from 64 to 74 ms[/quote:39ml5cud]
The DSP buffer size is the issue here.
[quote:39ml5cud]I’ve tried reduccing the DSP buffer size to reduce latency[/quote:39ml5cud]
It’s not so much latency that is the issue as it is resolution. The event system only schedules sounds based on velocity parameters at the minimum of the EventSystem::update frequency and mixer DSP block size. Assuming you’re testing this on PC the default block size is 1024. At a sample rate of 48kHz it works out to about 21.3ms, reducing the DSP buffer size can improve that resolution but there is still a limit.
[quote:39ml5cud]also tried updating FMOD from a different thread[/quote:39ml5cud]
A a side note, make sure you’re protecting against race conditions if you’re calling FMOD functions from multiple threads.
Do not lose hope however. There is a way…
- Create a Sound Def containing your 3 waveforms.
Set the following properties in the Sound Def:
Play Mode = Sequential
Spawn TIme = [1,1]
Play Count = 3
Maximum Polyphony = 1
Pitch & Volume Radomization = adjust to taste
Place your SoundDef on layer00 inplace of the three sound defs you currently have.
- Right click the Sound Def on Layer00 and set the following Sound Instance Properties:
Start Mode = Wait for previous
Loop Mode = Oneshot
Let me know how it goes. I can send you my project I used to test this if you have any troubles, just send an email to email@example.com.
It might be worth trying changing that to [1,1], it should try to schedule sounds ahead of time so that you don’t need quite as constant frame rate. Big frame drops will still be bad though. If you’re protecting against race conditions there should be no problem calling EventSystem::update from a separate thread.
Please login first to submit.