Sdl Sound Lag


deps

Still Fresh
Joined
Jul 23, 2007
Messages
31
Age
43
Location
Sweden
Website
Visit site
Hi,

I'm finally getting into GP2X development.
As my first game, I decided to steal borrow someone elses code. (With the original developers permission)
Problem is that it was written in Allegro, and I only had SDL up and running. So I rewrote parts of it and now have a fully functional version of the game on my GP2X. :D

Now for the problem... The game didn't have sound effects. So I added some using SDL_Mixer.
But it lags a lot! The game seems to run like it did before, but sound effects are playing much later than intended.
For example, if a unit is moved (it's a strategy game) I have a sound effect playing. In the code I play it as soon as the unit have moved and the screen is redrawn, but the sound is heard about a second later. Give or take some 100 milliseconds.

Is that "normal" for developers who use the code::blocks SDL bundle? Don't remember what RC it was, maybe 4. Found it here somewhere on this forum.
Or maybe it's a known bug in the SDL code for the GP2X?

Help! The game is almost finished, and I would hate to loose motivation because of some stupid sound issues! :lol:
 
int Mix_OpenAudio(int frequency, Uint16 format, int channels, int chunksize);

Try using a frequency of 11025 or 22050, and a chunksize of 128-512.
 
Ah, glad it worked. This is one of the most annoying things about sound on the GP2X.

I'm curious about your game, what kind of strategy is it? :)
 
"Dark Light Battles" by Richard Phipps.

It's a strategy game that was one of the entries in the 2005 Speedhack competition over at allegro.cc.

I'm done with the actual porting to SDL and GP2X, now I'm adding bits here and there and stuff. :)

Btw... Does anyone have a nice monospace TTF font? It should look good at about 10 points. The one I have now looks ok, but was probably designed for larger sizes. Parts of it dissapears. :p
 
deps said:
"Dark Light Battles" by Richard Phipps.

It's a strategy game that was one of the entries in the 2005 Speedhack competition over at allegro.cc.

I'm done with the actual porting to SDL and GP2X, now I'm adding bits here and there and stuff. :)

Btw... Does anyone have a nice monospace TTF font? It should look good at about 10 points. The one I have now looks ok, but was probably designed for larger sizes. Parts of it dissapears. :p
10 points at what dpi? :D

If you're going to turn on antialiasing, Bitstream vera looks good at just about any size. Liberation sans might be a little messier at small sizes but still very good. If you want a pixel font, here's a couple suggestions:

edit: whoops, you said monospaced. well bitstream & liberation both have mono versions i think.


This one looks similar to what the windows version of that game uses:

http://www.dafont.com/arcadepix.font

this one looks similar to the one in the windows build of the game.
 
Last edited by a moderator:
72DPI, according to the SDL_ttf documentation. Didn't know that. :)

I don't use antialiasing at the moment. Turned it off to speed things up. Might put it back on again since I have done some optimizations since last time I tried it.

Can I put Bitstream vera in the archive when I release the game? Don't want a bunch of lawyers kicking on my door.

Didn't know SDL_ttf could load .fon files. Will try them out, thanks!


Edit:

Arcadepix looks great! Thanks a lot! :D
 
Chunksize can cause strangeness if you don't get it right even on the pc. Settings that seem to work best for me on the gp2x for waves with a ok trade for size vs. quality:
Sample Size : 16-bits
Sample Encoding: signed (2's complement)
Channels : 2
Sample Rate : 22050

Bitstream vera is yours:

The fonts are distributed under the following copyright:
Copyright
Copyright © 2003 by Bitstream, Inc. All Rights Reserved. Bitstream Vera is a trademark of Bitstream, Inc.

Permission is hereby granted, free of charge, to any person obtaining a copy of the fonts accompanying this license (“Fonts”) and associated documentation files (the “Font Software”), to reproduce and distribute the Font Software, including without limitation the rights to use, copy, merge, publish, distribute, and/or sell copies of the Font Software, and to permit persons to whom the Font Software is furnished to do so, subject to the following conditions:

The above copyright and trademark notices and this permission notice shall be included in all copies of one or more of the Font Software typefaces.

The Font Software may be modified, altered, or added to, and in particular the designs of glyphs or characters in the Fonts may be modified and additional glyphs or characters may be added to the Fonts, only if the fonts are renamed to names not containing either the words “Bitstream” or the word “Vera”.

This License becomes null and void to the extent applicable to Fonts or Font Software that has been modified and is distributed under the “Bitstream Vera” names.

The Font Software may be sold as part of a larger software package but no copy of one or more of the Font Software typefaces may be sold by itself.
 
deps said:
Using freq 11025 and 128 as chunksice solved it!
If you are curious as to why this happened - here's a little explanation:

Just say you've open the audio device at a sample rate of 22050. The default chunk size might be 4096 bytes.
At a sample rate of 22050 samples per second it takes (4096/22050) about 0.2 of a second to play this much data. The entire sound buffer is usually split into a minimum of 2 chunks - the current playing buffer and the "next" buffer which is being rendered. There fore the minimum amount of time that a new sound can be played and heard is 0.2 of a second. This is very laggy. The smaller the chunk size, the quicker the response.

The disadvantage of smaller chunks is that they need to be updated more often.

So at a sample rate of 11025 with a 128 byte chunk the lag is about 0.012 of a second. You may get under-run, which means it's playing faster than the chunk can be filled. This may happen if your game is designed to run at a certain speed - like 60 frames per second. If this is the case, a 256 byte chunk size might be better, especially if the sound starts to play and stutters.
 
Last edited by a moderator:
Thanks for the explanation! :)
The game is not optimized much, so I would be surprised if it runs at 60 FPS.
But it's turn based so the player will probably not notice if it is in fact running at 10. :)

But at least the sound and music doesn't stutter. Will experiment a bit with 256 byte chunks and see if it starts to lag again.
 
Back
Top