SDL_mixer Mix_PlayAudio crashing when gui is loading

[sety]

Hi learned community,

I've been having a play with SDL to load and play MIDI files and it works beautifully, better than I was expecting, but only if there is no AES loaded (eg; MiNT with INIT=/bin/sh). In normal TOS or with xaaes running in MiNT I get a bus error.

I don't know much about this stuff but I'm guessing the SDL audio driver is trying to access some memory or audio device that the AES has reserved or is using?

My question is, how do disable that or get around it?

I'm using C with gcc cross-tools.

Thanks

[stormy]

Probably worth mentioning if you have memory protection on/off and also worth trying a different AES just to rule some things out. Like myaes for instance. There are also some falcon specific audio drivers in the freemint falcon driver folder, probably worth mentioning if some of these are in use.

[sety]

It works with memory protection on or off. It just doesn't work with AES loaded. Having said that, getting UNIX binaries to work on anything these days (even M1 Mac) is very difficult. File paths (/usr/local) are hard coded in the compiled binary and that doesn't suit for many OS.

[stormy]

Ok so you've tried with both memory protection on/off, both times it doesn't work with XaAES loaded. This could be an XaAES specific issue, so perhaps try MyAES to rule that out and then you'll be heading in the right direction.

[mikro]

Stupid question but are you 100% sure that this isn't a memory issue? I.e. it crashes because there's no free memory left?

Also, I'd check how big the stack is -- using the "stack" command -- and try to enlarge it.

[sety]

Stupid question but are you 100% sure that this isn't a memory issue? I.e. it crashes because there's no free memory left?

Also, I'd check how big the stack is -- using the "stack" command -- and try to enlarge it.

I was wondering that as well, although I'd have to be doing something pretty bad to fill up 512M of alt-ram. But then I have no way of knowing if it actually uses alt-ram. Tried adjusting the stack size but that didn't fix it.

When I try in Hatari it also crashes in the same way except that Hatari complains about Line F Emulator panic, and on the console from where Hatari runs it says this:

WARN : have to clip 1 chars from 'localtime'!
WARN : have to clip 2 chars from 'posixrules'!
DEBUG: FPU UNIMPLEMENTED INSTRUCTION/FPU DISABLED EXCEPTION PC=01003806

Not sure if that offers any clues?

[mikro]

That Hatari error could be disabled FPU in its settings? But good thinking, if you manage to reproduce it in Hatari, that will make your life way easier.

Btw, usage of Alt/TT RAM can be modified by the program flags. There is even a tool called "flags" which let you enable/disable various allocation flags. However, if your app calls Mxalloc() explicitly, the flags wont have any effect.

[sety]

Thanks guys. I'm just revisiting this and I've loaded my program into devpac monitor and run it and it crashes at this instruction:

move.l $4BA.w,d3

I don't know much about assembler but Google tells me that this is the 200hz timer. Any ideas? thanks

[mikro]

Seems like the Supervisor mode is not active.

[sety]

Thanks Miro! Enabling supervisor mode got me a little further!

It now crashes at an instruction jmp (a0)

I'm wondering if anyone might know any examples of SDL_mixer's timidity support working with cross-tools?

I've been looking at Patrice Mandin's demos that he ported from 68k assembly to SDL but from what I read, it sounds like the SDL versions were intended for PC. I can build the binary okay with cross tools but it also crashes in much the same way when run on Atari.

[mikro]

What about trying to build a working SDL_mixer example on PC and then compare its behaviour on Falcon?

[sety]

It behaves as expected when compiled for PC (Well mac x86_64 in my case) although it's using a completely different framework under mac. It occurs to me that SDL_mixer probably uses threads? I'm thinking it probably does because you can start the music playing and then continue on with your main loop without it blocking. That might be why it doesn't work in GEM?

Cheers and thanks again!

[Arne]

It now crashes at an instruction jmp (a0)

IMHO this could mean (depending on the number of bombs):

• A0 points directly at nirvana (2 bombs)
• the address in A0 is odd (3 bombs)
• the address in A0 is even and the bit pattern pointed to by A0 is an illegal opcode (4bombs)

[sety]

IMHO this could mean (depending on the number of bombs):

• A0 points directly at nirvana (2 bombs)
• the address in A0 is odd (3 bombs)
• the address in A0 is even and the bit pattern pointed to by A0 is an illegal opcode (4bombs)

I just installed FPU and tried it in 030 mode so I could see bombs (I'd been testing on CT60, mostly because I was too lazy to remove the CT60e to fit the FPU) and it's 3 bombs! What does it mean? Cheers!

[mikro]

It means trouble. :) Have you tried to ask Patrice on his build? Maybe he could give you some insight.