Sdl_mixer - Mix_setpostmix Causes Lockup

[ronybeck]

Hi,

I was wondering if any one has had the Mix_SetPostMix() function working before. I have some code working in linux which is simple enough to to run on the gp2x. The code I have is laid out like this:

CODE
Mix_SetPostMixvoid monoScope(void *udata, Uint8 *stream, int length)
{
//Monoscope code goes here
}

void startMonoscope(SDL_Surface *surface)
{
Mix_SetPostMix(monoScope, NULL);
}

void stopMonoscope()
{
while(!Mix_UnregisterAllEffects(0));
}


After I load a MP3 I call the startMonoscope function and then start playing the MP3. How ever the gp2x seems to lock before the MP3 is played. I worked out that it is the Mix_SetPostMix(monoScope, NULL) causing the lock up. If I comment it out, the code works fine. I checked the SDL_Mixer documentation and it seems to be correct what I am doing.

Can anyone suggest why this happens?

Thanks in advance

 

[senquack]

If you haven't already, I would try linking against various SDL libraries, especially the Open2X ones if you're not using them. If they don't work, you can find some in the file archive in archive.gp2x.de, I believe.

If all else fails, if it was me, I would try compiling Open2X SDL myself with debugging symbols enabled, -O0 optimization, no stripping of the binary. Then, compile your program the same way. Run it first, to ensure the crashing is still occuring, then run it using remote debugging in gdb (you must find the gdbserver binary, look wiki.gp2x.org for links and instructions). You control your program remotely from the computer and can pinpoint where in the SDL source code the problem occurs. If you leave your SDL source code in the same place you compiled it from, GDB will correctly reference the file and line of code the crash occurred in and can display variable values, frame traversal, etc.

 

[ronybeck]

If you haven't already, I would try linking against various SDL libraries, especially the Open2X ones if you're not using them. If they don't work, you can find some in the file archive in archive.gp2x.de, I believe.

If all else fails, if it was me, I would try compiling Open2X SDL myself with debugging symbols enabled, -O0 optimization, no stripping of the binary. Then, compile your program the same way. Run it first, to ensure the crashing is still occuring, then run it using remote debugging in gdb (you must find the gdbserver binary, look wiki.gp2x.org for links and instructions). You control your program remotely from the computer and can pinpoint where in the SDL source code the problem occurs. If you leave your SDL source code in the same place you compiled it from, GDB will correctly reference the file and line of code the crash occurred in and can display variable values, frame traversal, etc.

Thanks for that. I did try 2 sets of alternate SDL library sets. Both produced the crash at different points. But my development break out board arrived today. I can now see the errors I get from Mix_GetError() via a serial connection. I see the error:

Unrecognized music format

Now I tried this with both an MP3 and an OGG and I get the same error message. If I try playing a wave file, then everything works fine. I hear music and my monoscope works fine. So it seem there isn't any support for MP3's or OGG's in any of the libraries..............or I am missing something.

I am statically linking these libraries in the order of: SDL_mixer mikmod vorbisidec mad SDL pthread gcc m c

The libraries I am using rght now were found at: http://archive.gp2x.de/cgi-bin/cfiles.cgi?0,0,0,0,19,1240. But these are quite old. Are there newer ones? Does it matter that I am using a F200?

 

[senquack]

The libraries I am using rght now were found at: http://archive.gp2x.de/cgi-bin/cfiles.cgi?0,0,0,0,19,1240. But these are quite old. Are there newer ones? Does it matter that I am using a F200?



Those are ancient try the Open2X toolchain and look at Makefiles from source releases in archive.gp2x.de and on wiki.gp2x.org articles for examples of correct library linking order, that can be a real bitch to get working right. However, unless you are getting unresolved symbol errors during linking, you must have the order right for the time being.

 

[ronybeck]

Okay, I have solved this partially. If I only use MP3's and OGG's that are encoded in rates of 22050 or less, it works fine. So it looks like you can't play them at 44100. Unless I am doing something wrong.