GP32 Ringbuffer Code Crashing


pea

pea

developer
Joined
Oct 3, 2004
Messages
1,089
Age
46
Location
New Zealand
Website
www.projectitis.com
Hello all, especially Mr.Mirko :)

I am using the ringbuffer code in the Mr.Mirko SDK, and it crashes whenever the upper segment is written to (the lower segment is ok). The GP simply resets :(

The memory address of the upper segment is being debugged as: 209387520, which is C7B0000 in hex, which matches the numebr in GP32.h (so no problem with incorrect addresses!).

Any idea why?

I have not altered the Mr.Mirko functions in any way. And I call gp_initSound first.

Something else whicg may be related is that after calling gp_initSound, the GP starts clicking (a low frequency buzz like a cicada) even if I clear the ring buffer using gp_clearRingbuffer.

Apart from that libmikmod is very close!!

Cheers,
Peter
 
Update: If I alter it to use SAMPLEBUFFER1 it doesn't crash. And, would you know it, libmikmod is playing its first xm :p Skidmarks.xm - I guess from the amiga game.

I still want to solve the SAMPLEBUFFER problem though.

Also, the sound is very crackly. Can anybody download this test and see if they can tell what the crackling is due to? Its blu+, sorry! Will do another tomorrow.

www.gp32.co.nz/downloads/xmplayer_beta.zip

Place both player.fxe and the xm in GPMM, and run player. After loading the song you will need to press 'A' button three times to play the song.
 
Hi pea,
i'm sorry i can't help you with that ringbuffer problem.
i tried to download that beta player, and the link is broken for me :(
keep on working pea! libmikmod will be really usefull for me and for many other people!! :D
thanks
 
I can't because I use the official Gamepark data transfer stuff, and it'll PWN the xm (8.3 filename issue). :(

I can't rename it either, unless you didn't hardcode that filename into the program.

Sorry if I keep saying this over and over, but please look into the updated mikmod sources. ;)
 
Hi Drag,

everything is 8.3 compliant.
fxe is 'player.fxe' (6.3)
xm is 'skidmark.xm' (8.2)

Cheers,
Peter

EDIT: The mod is playing very slowly (I just checked it in winamp) and that may be the source of the crackles too, but I suspect not. The speed I presume is a clockspeed issue whereby the song no longer plays at the correct tempo.
 
Oh, I know it's 8.3, it's just the official file transfer thingy doesn't allow me to have any less than 3 extention characters for whatever reason.

Edit: Problem solved. Slubman Explorer saves the day! :) (rename the extension to XMM, and then back to XM with Slubman Explorer. :D)

And yes, it seems to be playing rather crackly. It's a regular crackle, not a random crackle, so I'd suspect whatever's making this mod play slow is also the source of the crackle, especially since mods get rather crackly in winamp when I use pitchfork to lower the pitch, because I'm weird and like to listen to music in different keys. :)

The text is offscreen to the left, just a bit, but I suspect that's just a side effect of BLU+ framebuffer init on a FLU (No ill effect on the player, in other words). :)

It's a wonderful start. :D
 
That 'crackle' is also present once the ring buffer has been initialised (when no music is playing yet) it sounds like a cicada, and fades slowly in and out too (over a period of about 10 seconds). I suspect it is related directly to the ringbuffer, and is related to the crash when the ringbuffer writes to the upper segment.

I presume that the crackle just keeps going when the music starts.

p.s. You should really put gpdrive on your GP. Its just a very small fxe. Then to transfer files, you run gpdrive just as you would any other program, and then (once it is running) plug in the USB cable. The PC now recognises the GP as a drive, and you can copy-paste anything to it. When you are done, 'eject removable drive' (on the PC), then press 'select' to cleanly exit gpdrive. Viola :)
 
In that case, multiple things could be wrong:

- The GP32 DMA sound bug. :p
- Accidently not writing to the entire ringbuffer (thinking it's smaller than it actually is, in other words)
- Possibly an 'incompatible' clockspeed (the song does kinda sound like it's playing at a lower pitch, but only slightly... the tempo is only slightly slower than winamp)

Also, I don't hear the clicking before the song starts.
"Loading
finished
start module (no sound yet)
play module (still no sound yet)
[hit the button again, song plays, this is where the clicking appears for me]"

Strange... something's up here, the BLU+ doesn't make THAT MUCH of a difference from the FLU, does it?
 
No. You are right - sorry - the clicking after 'init' has stopped. :)

I updated the drivers to use 22100 kHz sound instead of 44100 kHz sound, and the speed is now bang on. The crackling is still there though. I will look up info on the sound bug...
 
Oh ok, good. :)

Had me worried a bit. :p

Does this load ITs yet, or are there still problems with the sample decompression?
 
It wasn't IT loading specifically. It was IT compressed samples - which are used in a whole bunch of modukle formats, including XM. This is fixed now.

Looking up the sound bug, but it seems it is really only an issue when it is also highly graphically intensive, but I have no rendering going on at all at the same time.
 
pea posted on Mar 15 2005 at 10:57 PM said:
It wasn't IT loading specifically. It was IT compressed samples - which are used in a whole bunch of modukle formats, including XM. This is fixed now.

Looking up the sound bug, but it seems it is really only an issue when it is also highly graphically intensive, but I have no rendering going on at all at the same time.
​
Click to expand...

To make shure, you are not suffering from a DMA sound bug, recompile all stuff
with -O0
This will create very slow, but dma friendly code.
If the crackles changes now, its a dma bug ...
 
Last edited by a moderator:
Hello Mr.Mirko,

I just tried it just after I posted the last post. The crackles are still there :(
Maybe I am compiling the wrong code?

Should I recompile (with -O0 flag)
1) Mr.Mirko SDK sound functions
2) Libmikmod
3) My code that calls libmikmods update routine (see below)

Code: 
gp_debug( 1, "PLAY MODULE" );
while (Player_Active()) {
	/* we're playing */
	MikMod_Update();
}
gp_debug( 1, "FINISHED PLAYING" );

Cheers
 
My stuff works fine with -O3, so only recompile libmikmod with -O0. But if this will not solve the cracklings, it could :
a) your ringbuffer filling is wrong
B) there is still a dma bug

To be absolutly shure it is the dma bug, its the best way, to pre render some sound bytes, and playback them in a loop, without calculating new samples.

btw, have a look to the ym2149 player source on this site, its using my dma/sound setup, and playback all stuff in an irq, the guy did a great job...
 
Maybe it has something to do with SAMPLEBUFFER1.

The clicks are at a regular interval, not random, so I think this is definately a possibility.
 
I recompiled libmikmod with -O0, and no change. I think it is the sample buffer too.

Any idea why the ringbuffer would crash when writing to the upper segment of SAMPLEBUFFER0, Mr.Mirko? (lower segment is ok)
 
I fixed it guys.

I'm almost ashamed to say this - it was so fundamental :(
The problem was that I had set all the compiler flags in a CFLAGS variable, but then never used it in the makefile, so it was compiling at the default settings! i.e. it wasn't even using -mtune=arm9tdmi

It plays with no crackling now (still using SAMPLEBUFFER1) and now I will try to use the original SAMPLEBUFFER0 code to see if that works ok too, and also try it at 44100 kHz.

EDIT: 44100 kHz is fine, but refuses to work with FRAMEBUFFER0 - crashes when writes to upper buffer
 
No idea how much CPU power it uses. Whats a good way to test?
Click to expand...
What are you doing in the main loop while the music is playing?

Count how many of them you can do in a period before you start the music, and then count again while it's playing.
That'll tell you how much less time you have got.

Do each more than once and show the averages. When that settles move on to the next test.
But don't do page flipping as these can wait for a screen refresh before they return and it'll skew your result.


Hope this gives you some ideas ;)
Congratz on getting it all running :)
 
You must log in or register to reply here.

Similar threads

N
GP32 Timing Problem Or Is My Code To Slow?
Replies
8
Views
2K
nutribrain
N
G
Hardware Hangs When Trying To Read Mmsp2 Status Register
Replies
4
Views
3K
gfoot
G
skeezix
Minimenu Tab Plugin Spec .. Discuss Before I Code :)
Replies
9
Views
4K
skeezix
skeezix
T
Howto: Sd Card Recovery
Replies
0
Views
4K
tsh
T
Trip
Pimping The Manuals :)
Replies
9
Views
5K
Trip
Trip
Back
Top