I’m in the middle of replacing an existing DirectSound-based audio library with FMod, and am seeing a strange sort of channel-leak. Essentially, FMod never seems to release channels after they’ve finished playing them. The sound stops playing, but both Channel::isPlaying() and System::getChannelsPlaying() report them as continuing (although seemingly not 100% of the time). It generally starts dropping all sounds after reporting around 34 or 35 channels playing. Note that this happens regardless of how many virtual channels or hardware channels I set.
Unfortunately, because I’m replacing an existing system with existing content (we’re switching to get a fast software mixer), I can’t change the fundamental architecture without a huge amount of work (and I’m on a deadline). This means I’m basically stuck with it’s multithreaded architecture (that is, low-level audio calls made from multiple threads). I searched for multi-threaded / thread-safe issues, and discovered a thread posted a while back that mentioned that FMod Ex is not thread-safe, and probably wouldn’t be in the future. I suspect this may be causing problems, since I can’t see anything else going wrong. I’ve tried wrapping all calls in a common critical section, but it didn’t seem to help.
Naturally, it could be something completely unrelated that I’m doing to mess things up. But I can’t think of anything I could be doing that would fool FMod into thinking sounds are still playing when they’re clearly not. I’ve tried to reproduce this problem in a simpler sample app but have not been successful.
Can you think of anything that I’m overlooking or that I might try (other than rewriting the entire audio subsystem to avoid multithreading)? I’ve been banging my head against this for a couple of days and am just about at wits end. Any help or ideas would be greatly appreciated…
- JamesB asked 12 years ago
I’ll see if I can figure out a way to limit the calls to one thread in the code, and/or I’ll let you know if I can isolate the problem in a sample. Again, I wouldn’t have written it this way myself. The problem is that I’m replacing an existing API that is already called from multiple threads, and that’s somewhat difficult to change without a lot of rewriting. But it looks like I might not have a choice.
[quote="brett":3u70dpfm]Are you calling System::update once per frame, and i assume you are using the latest version?[/quote:3u70dpfm]
Yes, I’m calling update every frame, and I’m using version 4.02.04.
Just a quick update, the channel leak only seems to occur when using hardware DirectSound voices. If I set the software flag on sound creation, or initialize FMod to output to Windows mulitimedia, then this doesn’t seem to occur.
One other effect I noticed is that some of my looping ambient sounds are simply cutting out after one loop. However, the background music (which is manually filled using the Lock/Unlock functions on a background thread) seems to work consistently well.
The one thing that’s different between the two is that the background music Sound object is both created and updated all on the background thread. The normal sounds are created on a background thread (after the sounds are decoded for it), and then played on the main thread. Could this be causing these problems?
Please login first to submit.