TroubleShooting - Firelight Technologies Pty, Ltd.

# TROUBLESHOOTING

Introduction

This will cover some of the most common problems people come across when using FMOD. Remember if you have any problems just send a mail to support@fmod.org

FSOUND_Init fails on CE devices

This sometimes happens if the sound device is already busy, and the sound hardware will not release itself to FMOD until it finishes playing a sound.
This can happen when activesync starts up and plays the connection noise just as FMOD is trying to initialize.
To remedy this just initialize fmod in a loop until it succeeds, sleeping every 10 or 100ms or however long you prefer.
It is a good idea to timeout if it never succeeds then resolve the issue through checking the error code or stopping the program that is stealing the resource.
ie.
int retrycount = 0;
while (!FSOUND_Init(22050, 32, FSOUND_INIT_GLOBALFOCUS) && retrycount < 10)
{

Sleep(100);
retrycount++;

}
if (retrycount == 10)
{

/* Print error */

}
In this example it will keep retrying for about 1 second until it exits and prints an error message.

Stuttering/Skipping sound

More commonly known as buffer underrun/overrun, this can be 1 or a combination of factors
Bad soundcard drivers
This may be solved by upgrading your soundcard drivers. (Note it is recommended you get the latest drivers anyway)
CPU issues
Machine to slow, or whatever your are trying to do with FMOD is too cpu intensive! (ie playing 100 mp3's at once will most likely bring FMOD to its knees, or maybe a user stream callback or DSP callback is spending too much time executing).
Mixer buffersize is set too small
You can increase stability to combat these issues, by increasing FMOD's internal mixing buffer size. This will lead to greater stability but also larger latency on issuing commands to hearing the result.
Call FSOUND_SetBufferSize to alter this value (in milliseconds). It must only be called before calling FSOUND_Init, it will fail otherwise.
Please don't set this value to huge numbers like 2000 or 10000. It won't help increase stability and will consume larger amounts of CPU time and RAM.
First try a value of 100, then 150, then 200, and no more.
Stream buffersize is set too small
If you are using the stream API, you might be streaming off a slow media, such as CDROM or over network, or even a fragmented harddisk, and fmod needs more time to fill its streaming backbuffer.
For streaming buffers, fmod defaults to a 400ms stream buffersize. This is seperate to the mixer buffersize described above and not related.
Changing this value does not alter latency. Streams are pre-buffered and always start instantly no matter what the buffersize.
Call FSOUND_Stream_SetBufferSize to alter this value (in milliseconds). It must only be before opening a stream to take effect.
Setting this value to large values will cause larger cpu spikes (if a compressed format) and more memory usage.
Values around 1000 to 2000 max are recommended. Larger values are not.
Video Card Drivers
Yes video card drivers can affect sound output.
Always make sure you have the latest 3d/videocard drivers, and that your users are aware of this as well.
It has been noted that a bad VIDEO card driver can cause break ups and instability in sound output, as they are badly written and cause the bus to be taken over by the video card, not letting any sound data to be transferred to the soundcard.
This has been noted on S3 Virge and Voodoo 1 drivers so far, so always remember first to have the LATEST video driver, and make sure you note this in your documentation as well upon distribution.
Frame-rate is too high!
Yes this can also affect the sound output, for the same reasons as described above. Excessive calls of the video driver can force the sound driver to not be serviced. It has been found that introducing a frame-rate limiter will solve this problem.
Output type
FSOUND_OUTPUT_DSOUND will provide more solid output than FSOUND_OUTPUT_WINMM in anything except NT.
This is a problem with Windows Multimedia Services not being as realtime as it should be.
Under NT FSOUND_OUTPUT_WINMM is more stable, as DirectSound in NT is just emulated by using WINMM itself and is actually slower and has longer latency!.
NOTE: Please don't feel the need to use FSOUND_SetOutput if you don't need to. FMOD autodetects the best output mode based on the operating system.