Been using SDL for years with no issues (shipped 5 SDL games so far).
Audio is skipping in my latest game during CPU-intensive moments. Trying to figure out why, I tried adjusting the buffer size (SDL_AudioSpec.samples) in my call to SDL_OpenAudio. Seemed to have no effect, which was surprising.
Trying to figure out why buffer size was having no effect on drop-outs, I discovered that whatever size I specified was being ignored. In the “obtained” return parameter of OpenAudio, I’m seeing 470 samples always, with a full buffer size in bytes of 1880 (16-bit, stereo samples, 4*470 = 1800).
I’m also seeing this same byte length 1800 in each callback call. I’m guessing that it’s simply too short to weather CPU-intensive moments in my game. But how can I change it? And where is 470 coming from?
I’m testing this on Ubuntu Linux (old version, Fiesty). Here’s the output of my sdl-config:
sdl-config --version --cflags --libs --static-libs
1.2.11
-I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT
-L/usr/lib -lSDL
-L/usr/lib -lSDL -lpthread
From some of the error messages that I’ve seen when the audio device is already in use, I believe this is ALSA-backed SDL. Yeah, if I have my MP3 player going when I launch my game, I see this:
ALSA lib pcm_dmix.c:864:(snd_pcm_dmix_open) unable to open slave
Here’s my code:
SDL_AudioSpec audioFormat;
/* Set 16-bit stereo audio at 22Khz */
audioFormat.freq = soundSampleRate;
audioFormat.format = AUDIO_S16;
audioFormat.channels = 2;
//audioFormat.samples = 512; /* A good value for games */
//audioFormat.samples = 1024;
audioFormat.samples = 8192;
//audioFormat.samples = 8;
audioFormat.callback = audioCallback;
audioFormat.userdata = NULL;
SDL_AudioSpec actualFormat;
/* Open the audio device and start playing sound! */
if( SDL_OpenAudio( &audioFormat, &actualFormat ) < 0 ) {
AppLog::getLog()->logPrintf(
Log::ERROR_LEVEL,
"Unable to open audio: %s\n", SDL_GetError() );
}
else {
AppLog::getLog()->logPrintf(
Log::INFO_LEVEL,
"Successfully opened audio: %dHz, sample buffer size=%d\n",
actualFormat.freq, actualFormat.samples );
}
No matter which buffer size I pick there, I get this printed in my log:
L4 | Sun Nov 21 18:46:00 2010 (679 ms) | general | Successfully opened audio: 22050Hz, buffer=470
I’m going to DL the SDL 1.2.11 source tarball and take a look eventually, but I’ve been unable to find anything about this problem online. Yeah, various docs say, “The audio hardware may pick a better buffer size for you.” The other thing I’ve found, when searching for “sdl audio 470” is that some other games on Linux seem to get stuck with that value as well (people debugging other problems often include the printout from the game’s audio layer, which reveals a 470-sample buffer size).
Maybe this was something fixed in SDL 1.2.14 with “Updated ALSA support to the latest stable API”.
Any thoughts?
Jason