I’m facing some problems when using FMOD’s libraries. Everything’s working correctly, except the playing of the audio using FMOD’s library. The funny thing is that the issue i am facing differs from computer to computer. Some worked perfectly fine (no issues), others not too good at all.

What I’m trying to do:
1) Decrypt an audio file, which will be stored in memory
2) Get FMOD to play the decrypted audio file

//decrypts the audio file
int audioLen = 0;
decryptedAudio = DecryptSound(out audioLen);

//creates FMOD.Sound
createSoundExInfo.cbsize = Marshal.SizeOf(createSoundExInfo);
createSoundExInfo.length = (uint)audioLen;
createSoundExInfo.suggestedsoundtype = SOUND_TYPE.OGGVORBIS;

ref createSoundExInfo,
ref sound);

//checks if createSound() returned FMOD.RESULT.OK

It seems that there’s some change in the time where FMOD plays the audio file i targeted (ie, the audio file plays too early/late) I’ve checked through the entire program, ran tests and concluded that the problem’s coming from the use of FMOD’s libraries (perhaps I used them wrongly). I’m wondering if i could use some suggestions here.

Here’s some videos showing the problem i’m facing, both being run with the same executable but on different machines.

Correct Behavior

Incorrect Behavior (Song’s about a second ahead)

  • You must to post comments

Hi RP-34, welcome to the FMOD Forum!

I can see what you mean with the second video being out of sync. The code you have posted for loading the decoded ogg audio data does not look like it would introduce any variable latency. If you were using NONBLOCKING loads and attempt the play the sound before it finishes loading that can cause a delay but you don’t appear to be doing that here. It’s hard to say exactly what is going wrong there without a bit more information. How are you syncing up the visuals and the music and the sound effects?

  • You must to post comments

Hello Peter,

Thanks for the welcome!

I’ve managed to eliminate and trace to the cause of the problem after 2 weeks. Apparently, like what you mentioned, those calls to FMOD didn’t introduce the latency issues. It was something else instead and it has been solved recently. Thank you so much for your response to this topic, it’s appreciated! =D


  • You must to post comments

I was looking into the FMOD Wrapper’s MODE enumeration when i noticed something.

For the following FMOD API:

createSound(byte[] data, MODE mode, ref CREATESOUNDEXINFO exinfo, ref Sound sound)

If i have the MODE be set as: MODE.DEFAULT | MODE.SOFTWARE, that’ll be logically be equivalent to only MODE.SOFTWARE right?
MODE.DEFAULT is defined as 0x00000000 and;
MODE.SOFTWARE is defined as 0x00000040.

  • You must to post comments
Showing 3 results
Your Answer

Please first to submit.