GP32 Sound Questions

[Kai]

I write MIDI on my computer using Logic Audio Platinum.

I was wandering something... when I extract my work as a MIDI file, rather than saving as a Logic file, and I play in Winamp, I odn't get all the sounds. Instead I get just a piano playing EVERY track. You can imagine how annoying this can get.

Anyway, I recieved an email from someone from a GP32 forum somewhere, asking if I'd be interested in writing some music for a GP32 game. Naturally I jumped at the chance, and as soon as I oculd, wrote a very very short piece, before realising my problem with Winamp.

I was wandering if there is any way to get the GP32 sound/MIDI banks or whatever the hell is in there onto my PC at home so I can get some sounds right and then make life a litte easier (actually, make that a whole lot easier) to work with.....

Can anyone help?

 

[Feeblez]

do you want the bad news or the bad news? :lol:

simply put ... the gp32 does not support MIDI in hardware,
although looking at gamepark's website it is easy to think that it does! :rolleyes:

next bit of bad news ... gamepark _still_ haven't got around to providing MIDI support through software, even though the MIDI commands are clearly listed in the SDK! :rolleyes:

GpMidiPlay
GpMidiListPlay
GpMidiStop
GpMidiPause
GpMidiReplay
GpMidiStatusGet

it's not all bad news tho ... the author of gpScumm managed to implement MIDI playback in his software, so it is possible, but as far as i am aware MIDI playback code is not readily available.

hope this hasn't ruined your plans! :lol:

 

[Feeblez]

okay now! ... i have a question about sound ... something i have been trying to resolve for quite some time now ... and what's stopping me releasing my 1st gamepark game ... and then going on to do a shit load more!

so i hope it can be answered once and for all!

right! ... pcm playback!

the playback sounds good and clean ... that is until i blit anything to the screen, at which point my sound effects turn to shit! :angry:

this has been mentioned a few times before as a hardware/sdk bug that has to be programmed around, but how exactly do you program around it?

people on #irc have told me to just use CHN's sound code (gpsoundbuf.rar) as it works 'perfectly'

if anyone doesn't know ... CHN's code creates a looping sound buffer, a callback function is triggered by a hardware interupt, and from there you 'mix in' all your sample data ahead of the playback cursor. (from what i can make out it is a 2 second buffer)

this is good for mod players and emulators, but a bit too messy for newbie coders who just want a simple function to trigger a sound effect.

also i'm not 100% convinced a looping sound buffer as described is going to fix my problems, as i already have a looping sound that gets effected by my blitting.

i tried a few things tonight from CHN's code to try and fix my sound, but i must admit i haven't used it completely as intended yet. (but i will do soon)

this is what i 'think' is causing the distorted sound, the GpBitBlit and GpRectFill functions (and most likely gp_memcpy/gp_memset) are optimised to use DMA routines, but the sound also uses DMA and this causes a conflict/stall. (well with nothing else to go on it kind of sounds feasible! you explain it then!)

the other thing i've thought is that maybe the call to GpPcmPlay is too expensive while you are doing other stuff, in that case creating a single looping buffer at startup and mixing in data on the fly may be the only way to go, although this is exactly what the SDK should do! (and as mentioned before, not the easiest system to manage)

i will be very, very interested to hear other people's experiences with pcm playback, if they have experienced crappy sound also, and if so how they got around it!

i know skeezix has posted something about crackly sound during development of Castaway/GP, but it doesn't really help me here.

i'm also interested to know what kind of sprite routines people use, wether they use GpBitBlt, GpRectFill etc. or have made their own versions. (i'm considering this)

Many many thanks for reading this far!

 

[Nitro]

Have you tried playing a sound while blitting, but not using GpRectFill ? I found that GpRectFill was one of the slowest functions I'd come across graphics wise and therefore not really useful for clearing the screen.

 

[Kai]

OK, so its just a question of waiting for someone to write a program that can implement MIDI into the GP32?

Therefore, who's up for it?!

Does the GP32 play WAV files and/or MP3 files in games?

Cos on Logic, I can download some EXT24 intruments, and get some sweet sounds, and then export as a wav file....

 

[Feeblez]

you have to convert your WAV files to Raw PCM ... but as you may have heard i am having a lot of problems with sound distortion when drawing to the screen!

MP3 playback takes quite a chunk of processing power, so it probably isn't very feasible for a fast action game ... and again it's a case of getting your hands on some MP3 playback source as gamepark don't provide anything in their SDK.

i would say Mod files are probably your best bet for games, as they take less processing power and mod source is freely available, again thanks to CHN.

 

[Feeblez]

Have you tried playing a sound while blitting, but not using GpRectFill ? I found that GpRectFill was one of the slowest functions I'd come across graphics wise and therefore not really useful for clearing the screen.

dohhhhh! i'm stupid!

well after weeks of pissing about and pestering people on irc my game is 'sounding' good at last! :unsure:

i knew that when not rendering any graphics the sound was clean (or clean'ish)

i had tried replacing GpRectFill with my own rectangle fill but i was still getting the same distorted sound problems.

anyway, let me explain further...

my graphics are about as retro looking as you can get, so i wanted to clear the screen every frame.
(probably would have been better to just erase the previous frame's sprites at the start of each frame, but i'm too lazy for that!)

anyway without clearing the screen (using whatever method) then all the sprites would leave snail trails which made it kind of difficult to test!

so lastnight in desperation i created a 320x240 'black sprite'! ... and when i ran the game i was rather suprised, annoyed, happy, sad, confused... my sound was now perfect and better than ever!

and today, now i have re-read skeezix's post on the subject, it all makes sense, and his advice was spot on!...

http://www.gp32x.de/board/index.php?act=S...f=16&t=1314&hl=

so thankyou skeezix ... i think i have now learned the moral of the story!

so i don't think its that GpRectFill is too slow, but quite the opposite (as i had suspected earlier, but for the wrong reasons), it's too fast! and makes heavy use of the instruction cache, which has a knock on effect for the sound playback.

and it looks like all the rectangle drawing routines of my own were getting too optimized by the compiler aswell.

bah! well we have to find out these things someway i guess... curse you retro stylee game!

 

[Kai]

you have to convert your WAV files to Raw PCM ... but as you may have heard i am having a lot of problems with sound distortion when drawing to the screen!

MP3 playback takes quite a chunk of processing power, so it probably isn't very feasible for a fast action game ... and again it's a case of getting your hands on some MP3 playback source as gamepark don't provide anything in their SDK.

i would say Mod files are probably your best bet for games, as they take less processing power and mod source is freely available, again thanks to CHN.

Hmm, I think Im abit too dense, I'd have no idea how to do taht or even what raw PCM is lol....

thanks anyway

 

[Toris]

Yes Feeblez, that's correct, after I found out with a lot of experimentation.

The reason is, for some reason, when you write something to memory, lots in succession, without giving it time to write, it creates problems, such as display flicker/scanlines, and sound corruption.

So, either, you write your own function to clear the screen buffer, doing something like a NOP after each STR (assuming ASM of course), to give the memory time to write, or, as you say, use a 320x240 sprite, the reason this works, as it has to read from memory, before it writes to it, giving it time to write the memory before you write again.

I think this ought to be documented somewhere where all coders will see it, it took me about 2/3 days to fault find my code to find what was causing the problem.

Also, contrary to what Skeezix says, you *can* use the -O3 compiler option, assuming you do a small wait after each memory write, this may, or may not, give a speed increase, depending on your code (the -O3 option, not the wait after each memory write).

 

[Mofokubik]

you can always send me the file, ill fix it right up with sonar... (i write midi too, but also do some heavy soundfont design)

mp3 = everyone knows what this is
raw pcm = has to do with the compression of a sound file
mod = midi with waves in it, so it uses samples stored in the music file it self, but still much diff than midi.
rmd = rmd files contain both DLS banks and MID songs in it. I dont know much about this though =/
dls = a software alternative to creatives sf2 soundfont (makes the midi sound much much better, in most cases anyway)

 

[Feeblez]

raw pcm = has to do with the compression of a sound file

Raw PCM is 'uncompressed' raw data with no header!
(what the hardware likes)

 

[Mofokubik]

it still has to do with compression, becuase its uncompressed, am I making sense?..I dont think I am lol