I am totally new to FMOD, but am an experienced programmer.
I’ve been writng a framebuffer app to act as a media player for my house.
It’s all going nicely, using a separate program to do the sound related stuff (my app is really only a manager/categoriser etc). I was getting annoyed at the slowness of the other app (communicating via named pipes), so decided to implement my own sound code.
Written an MP3 decoder before, but it was messy and FMOD looks great, so decided to adopt that.
Here is my problem: After a call to fork (which I do to create a framebuffer recovery thread – which is handy if you’ve ever gotten a seg fault in a framebuffer app as you can’t see anything until a reboot!!!), FMOD will not initialise.
My first fork, uses the parent process to sit and wait for stuff to happen and the child process goes off and runs the rest of the program.
If I try and init fmod from the parent process all is fine, but if I try and start it from the child (i.e. the return value of 0 from fork()), it just hangs. I reckon that fmod must use a similar technique as I am with my frame buffer and that things are getting deadlocked.
With out a quick peak at the source code I am not able to diagnose this. Does this seem likely?
Is there a trick with process groups that can be done?
Thanks for any feedback. And BTW fmod would appear to rock!
- siege79 asked 14 years ago
Thanks for that.
I seem to be getting on OK with out the safety fork anyway, but I think you’re probably right.
One of the system calls musn’t be thread safe.
Cheers for the info. If there is anything I can do to help, please just let me know.
It gets worse!
Sorry for the disjointed post, but FMOD initialisation really screws my program up.
First off, the thread thing is still a problem, but confident of what I’d done already, I disabled my recovery thread!!
If I initialise my framebuffer, FMOD initialisation hangs.
So I figured (despite it really not being how my program should work) I’d init FMOD first. This caused my Framebuffer stuff to hang on it’s initialisation (not touching threads now!)
I traced it to a popen call (having the source code this way round!!) which just froze. I was using popen to save compiliing in gz support (libz) when opening compressed files. This way I just do a popen to a “zcat filename” and I get the data. Works fine and no hassle normally. Anyways, I manually gunzip the file for the purposed of testing (so it’ll use fopen rather than popen) and it gets past this stage, but freezed on redraw of the display. I’ve now given up with the debugging as there is obviously something bad wrong if popen fails.
Both FMOD and my framebuffer code do lowlevel IO stuff, so I am guessing something is conflicting. Does FMOD do anything with the controlling TTY?
If it helps, I’d be happy to supply a tarball of my code for testing (be warned about Framebuffer though – have an ssh server running just in case!)
I should really test things properly before posting!
popen bug was repeated twice, and now things kinda work. Initialising the sound first, then the framebuffer, and not having a recovery thread.
1. FSOUND_Init hangs if it is not the parent thread. I’ve included some test code below.
2. I think we both must use popen and that it is not overly thread safe. Ahh well. I think I can avoid it if I compile in libz instead.
Incidentally, if I take out my calls to popen, I can init my framebuffer first without any hassle. To that end, my last post was more or less pointless!!! Sorry for the mess.
=======Test Code to demonstrate Hang==========
include “fmod_errors.h” // optional
int main(int argc, char *argv)
std::cerr << “Attempting to Init Sound\n”;
if (!FSOUND_Init(44100, 32, 0))
std::cerr << “Error: “
<< FMOD_ErrorString(FSOUND_GetError()) << std::endl;
std::cerr << “Init Sound Success\n”;
Please login first to submit.