GP32 Playing sounds without crackling ?


Nitro

Member
Joined
Jan 22, 2003
Messages
172
I'm playing my sounds with GpPlayPcm() or what ever its called, and if I play small sounds, I tikn its okay, but if they sounds are longer they tend yo crackle a lot. I'm not using RectFill, but I suppose there is quite a lot of sprites on the screen at certain points. Using gp32's built in functions to play a wav file as music in the background appears to be a definate no-no. I've tried using various modlibs to play some mod music, but I haven't been able to get any of them working (even though the first time ever tried, it worked perfectly o_O)... I'm wondering if its to do with using Devkitadv instead of Minigp32...

I guess what I'm trying to ask is:

Is there a decent alternative to using the GP32s sound playing functions?
and any ideas what might be causing the problems with mods not playing?

Any help would be much appreciated. I had a look around but couldn't find anything very useful. If I can get these two problems out of the way, then you'll see a lot more games coming from me :)

-Nitro
 
Afaik the main problem is that the sound transfer DMA can't access the bus because the CPU is hogging it.
One thing you can try is to lower the bitrate etc..

---
mithris
 
I lowered it right down in the first place so that it wouldn't take up too much ram (about 300kb). Even like this it still crackles a lot. If I could just get the mod player working again I'd have most of my problems solved. Anyone have any working source which uses one of the modlibs? :/
 
Few basic things.. make sure that memory areas used by DMAs (including sound & LCD) have no writeback cache enabled. Also avoid too "optimized" code when writing to memory, which can cause, as Mithris said, CPU to hog the bus and in that way lead to IIS FIFO (sound buffer) under-runs. These problems and work arounds are documented in Samsung's manual chapter 25. :blink:
 
Hi everyone !!

Personnaly I don't think you can hog the bus just by using much the cpu (as in my program there can be 300 units in one map, but no sound bug).
What I would recommend for good sound quality is hitmen's code (DMA2 with irqs, with volume control...). Be careful his irqs are not setup correctly, so the DMA2 would stop the rest of the GP32. In GPFMSRC you can find a good example for the interrupt handler.
 
mATkEUpON.. believe me.. I (and Mithris too) know what we are talking about, at least when it comes to GP32 related things (no offence) <_<
300 units? i.e. 300 sprites? what size & depth? :blink:
 
Well if you didn't try my **full sdk** demo of my game (ie the 15dayscoding one) which runs at 133, with 200 units (with base & turret + selection if you want, which can give, if you select the whole screen, 80 * 5 blits (the selection makes 3)) + background for each frame and no sound bug. I've put a version which runs at 66, with the same amount of units and use of the dma for background copy (the whole screen in one dma) and no sound bug either (well, when scrolling the thing gets ugly, as my dma doesn't mix with the sdk gpbitblit and i have to use my own blitting routines).

You can find the 66MHz here (doesn't work with emu anymore):
http://membres.lycos.fr/matkeupon/demo/gpfw.rar
 
This is getting kinda ridiculous.
The info is there, in the documentation.
Read it and judge for yourself.

---
mithris
 
I definitely confirm the dma bug : in opensnes9x I have to use a slower
clear buffer function when sound is on.
the bug is well documented in chapter 25 of the samsung docs and can be
easily reproduced by doing lots of stm/str while having looping sound output.
 
OK I guess in asm you can hog the cpu enough, but as I don't use asm (no yet) I couldn't tell. But unless Nitro is using asm, I think there is no reason for his sound to crackle, even with quite a lot of sprites.
 
I managed to fix the problem :) I think it was a problem with the file I was loading, the bit rates, khz and all that. and also my file loading routine wasn't exactly how it needed to be. It's all good now, though. Hopefully it will stay that way :lol:

Thanks for all your help though, guys. :)
 
Nitro posted on Dec 23 2003 at 06:17 PM said:
I managed to fix the problem :) I think it was a problem with the file I was loading, the bit rates, khz and all that. and also my file loading routine wasn't exactly how it needed to be. It's all good now, though. Hopefully it will stay that way :lol:

Thanks for all your help though, guys. :)
As I suffer from the same problem, i'd be really glad if you could show me a code example for loading and playing stuff.

Regards, Don.
 
Last edited by a moderator:
Back
Top