Sorry if this is more a linux question than FMOD question, but i’m not sure what the answer will tell.
To run FMOD without cracks/glitches in the sound when CPU is under heavy load, i’ve increased the priority of my process on windows.
But on Linux, this doesn’t seem to be possible except if the user of the process is root. Is there some other way to fix this or get around it?
Just increasing FMOD’s buffer sizes isn’t enough.
- MrFruxo asked 10 years ago
Excellent, it’s good to hear that fix is working for you. I will evaluate upgrading the older branches with the ALSA changes too. Also I think I need to do a pass on the OSS code as well and get it working a bit better at some point.
The main way to reduce crackles or glitches is by changing the DSP buffer size, what values have you tried to reduce the problems? Also what output mode are you using OSS, ALSA or ESD?
Currently the mixer thread which is feeding the sound card already runs at the highest priority it can to ensure there is no stuttering. On Linux this is priority Very High I believe, which is the highest a non root user can set a thread to run at.
It is using the default output mode and fmod_system->setDSPBufferSize(1024*3, 4).
Maybe it is not a problem with the mixing thread, but with accessing and decoding data (or is that done in the same thread?). FMOD is being used to play mp3 files (streaming mode) from local disk or via lan.
The crackles appear f.ex when i’m compiling something big, so the HD will be working hard during that time. If i increase the buffer it happens more rarely, but that means quite a large buffer to just minimize the problem instead of getting rid of it completly.
In windows, increasing the priority of the app helped completly. I wish i could do it in linux too, but setpriority fails if the user is not root.
- MrFruxo answered 10 years ago
If you are streaming over a LAN or a very busy disk your stuttering is probably coming from the stream buffer under-running. Try tweaking the stream buffer size using System::setStreamBufferSize(). The default stream buffer size is 16k, I suggest trying something larger, for instance our net streaming example uses 64k to account for internet latency.
I’m having the exact same problems. When the cpu is under load (don’t know about disc, but in my case it isn’t) the sound crackles and skips.
I’ve disabled FMOD in my program (OpenGL demo), and run it so the CPU/GPU is under load. Then I start the example "playstream" program, and then the sound is broken too! Playing music with mplayer the sound is not crackling/skipping, but just playing as normal.
Using OSS driver, the sound mostly skips. Using the ALSA driver, the sound mostly crackles.
I’ve tried to increase the DSP buffer, but that does not help. I’ve tried to increase the stream buffer, but that does not help either.
FMOD_System_GetDSPBufferSize(fmSystem, &fmBufLen, &fmNBuf);
FMOD_System_SetDSPBufferSize(fmSystem, fmBufLen8, fmNBuf);
FMOD_System_GetStreamBufferSize(fmSystem, &fmFileBufLen, &fmTimeUnit);
FMOD_System_SetStreamBufferSize(fmSystem, fmFileBufLen4, fmTimeUnit);
Any more thoughts on how to fix this? I’m using the latest stable FMODEx (libfmodex.so.4.12.07)
Thanks for your patience, I haven’t been able to reproduce your stuttering here but I did have a good look at the ALSA output mode code. I have done a lot of changes that should improve any stuttering issues, the old code wasn’t correctly respecting the DSPBufferSize settings so you probably wouldn’t see any change when setting different values.
This is a pretty big change so I will only be putting it into our development branch (4.15), at least until it has had a bit of testing by more people (Linux can be temperamental some times).
If you could try this fix out and report back your findings that would be great, the new release should be tomorrow or early next week so keep your eyes peeled.
I’ve just downloaded the 4.15.0 version, and at first I thought it didn’t work, but then I checked the code, and the driver was set to OSS, not ALSA.
After changing to ALSA, the song played perfect without any skipping or distortions. Thank you very much
PS. We’ve also rewritten our pixel shaders and framebuffer code, so it works correctly, and does not hog the cpu/gpu. That already fixed the problem with a decent video card, but this will surely fix it for all systems.
Please login first to submit.