Crackle at the end of short sounds

FMOD Engine
1

Fmod version is 2.01.05
I have a very primitive API for modding purposes where users can create a Sound object and play that via System::playSound() This gives them all the control over sounds without having to setup any Fmod Studio project and generally users are quite happy with the interface.

However some users are experiencing strange problems:

  • when they use some sounds (seems to mainly affect short sounds) they hear a crackle at the end of the sound
  • sometimes vanilla game audio cuts out as if all its channels are stolen, that happens event when just one modded sound is playing
  • eventually all game sound will die from this and never recover, while the Fmod API never returns any error codes

While investigating the issue it seems to me that issue 1 plays a role in triggering issue 3, however issue 2 always happens to some degree. I also can’t share the files that users experience this with since they are using audio files from Minecraft and I don’t want to share copyrighted material.

Some more technical details:

  • The sounds are all created from raw PCM that is loaded in by a third-party library from various file formats.
  • I inspected the waveforms after load and they don’t seem to have any wrong data.
  • The worst offenders are all <1s long audio files (Minecraft mining sounds).
  • I have two master channel groups, sfx and music, that users play their sounds on.
  • The channels are not playing infinitely for some reason, they all successfully return FMOD_OK from ChannelControl::isPlaying while setting isplaying to false.
  • All the features are of course hidden behind an API, so there likely is no user error. The API is used roughly like this
sound = create_sound("path_to_my_sound.wav")
playing_instance = sound:play()

What could I be doing wrong here? Or are there any settings that I should try in order to improve the situation?

2

The best would be to get a Live Update session of this happening. Try to get the samples the users are using and get a recorded profiler session. This might give some insight into what is happening.

This leads me to think the sounds are somehow too loud and causing the FMOD system to mute it’s master bus to prevent any damage from occurring. Again, a recorded Live Update session will help us to determine is this is the case or not.

3

Unfortunately I don’t have the source code to the project I am adding modding support for. So I think doing a profiling run is probably not very feasible. But I will verify your thought of the sounds being too loud, perhaps there is something wrong with loading the files into memory on my side after all since it always appears to be the end of the clip that seems to cause problems.

4

@richard_simms perhaps this should’ve been faster for me to realise, but the issue disappears when I use the following flags
FMOD_MODE mode = MODE_CREATESAMPLE | MODE_OPENMEMORY | MODE_OPENRAW | MODE_IGNORETAGS | MODE_LOOP_OFF;
Instead of what I used before
FMOD_MODE mode = MODE_CREATESAMPLE | MODE_OPENMEMORY_POINT | MODE_OPENRAW | MODE_IGNORETAGS | MODE_LOOP_OFF;

As you can see the only difference is between MODE_OPENMEMORY and MODE_OPENMEMORY_POINT
It would be ideal if I could keep using MODE_OPENMEMORY_POINT to avoid additional allocation cost, considering that the creation of sounds is in user hands. Is there some preprocessing that needs to happen in order to be able to use MODE_OPENMEMORY_POINT?`
All data currently is is just an array of floats, so using PCMFLOAT as a format.

5

With FMOD_OPENMEMORY_POINT and FMOD_OPENRAW or PCM, if using them together, note that you must pad the data on each side by 16 bytes. This is so FMOD can modify the ends of the data for looping/interpolation/mixing purposes. If using a WAV file, you will need to insert silence, and then reset loop points to stop the playback from playing that silence.

You won’t have this issue with compressed audio, just PCM, because FMOD resamples directly from the user’s memory buffer when it is PCM - which could have garbage on either side of it

https://www.fmod.com/resources/documentation-api?version=2.2&page=core-api-common.html#fmod_mode

6

Aha, okay, I missed that part in the docs. I will try to pad my data and see if that resolves the issue.
I’m not sure what you mean with “if using a WAV file”. After reading the WAV file in I still have only PCM data, so it shouldn’t matter if it comes from a WAV or an OPUS, right?

7

You’re correct - if using OPENRAW you have a buffer of your own memory, and copied some PCM data into it, so wherever it came from (WAV/OGG/whatever) is irrelevant.

The documentation is talking about if you point to the raw PCM inside a WAV file, then it might read parts of the header/WAV metadata and make it audible.