We have released this new version, with new graphics and network
support.
Of course, the game is OPEN SOURCE.
By clicking in the banners you help me to mantain the development.
Thanks.
Hi,
There is a slight disagreement among myself and my codevelopers
about where the audio should be mixed in an SDL application. We’re
developing an application that outputs a special type of audio. There’s a
routine that mixes a fraction of a second of audio into a buffer. There’s
disagreement on whether that routine should fill up an audio buffer in the
main program thread or in the audio callback. It’s not anything as
computationally-expensive as an MP3 stream, but suppose it was? Should the
main thread decode the audio into a buffer and then just let the audio
thread copy it into the SDL audio stream? At what point in the audio
callback does the SDL start using the copied data? Does it start using the
data copied into *stream as soon as it needs the data, or does it wait
until the audio callback has exited?
I hope that last question was clear. Another question: Right now,
I have a circular buffer to mix the audio and feed it to SDL and I’m
having the worst time trying to get it to wrap around properly. Is it not
a good thing to do 2 copies into the *stream buffer during the audio
callback? I’m hearing some audible imperfections every second when it’s
time to wrap around.
Thanks...
-The Mighty Mike Master
http://tmmm.simplenet.comThere is a slight disagreement among myself and my codevelopers
about where the audio should be mixed in an SDL application. We’re
developing an application that outputs a special type of audio. There’s a
routine that mixes a fraction of a second of audio into a buffer. There’s
disagreement on whether that routine should fill up an audio buffer in the
main program thread or in the audio callback. It’s not anything as
computationally-expensive as an MP3 stream, but suppose it was?
You generally have a little less than the amount of audio that you have
buffered to perform the mixing. You shouldn’t do any memory manipulations
in the callback routine, just data copying and processing.
In general, you will get better performance, if you have low overhead in
the mixing, by doing the decoding in the callback, but if the processing
overhead is too high, you will hear skips in the audio. The best thing
to do is test it on your baseline system and see how it sounds.
At what point in the audio
callback does the SDL start using the copied data? Does it start using the
data copied into *stream as soon as it needs the data, or does it wait
until the audio callback has exited?
It waits until the audio callback has exited.
I hope that last question was clear. Another question: Right now,
I have a circular buffer to mix the audio and feed it to SDL and I’m
having the worst time trying to get it to wrap around properly. Is it not
a good thing to do 2 copies into the *stream buffer during the audio
callback? I’m hearing some audible imperfections every second when it’s
time to wrap around.
You can copy as many times as you like:
while ( len > 0 ) {
if ( mixable > len ) {
mixable = len;
}
memcpy(stream, buffer, mixable);
stream += mixable;
len -= mixable;
}
etc.
Thanks…
No problem. 
-Sam Lantinga (slouken at devolution.com)
Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec
In general, you will get better performance, if you have low overhead in
the mixing, by doing the decoding in the callback, but if the processing
overhead is too high, you will hear skips in the audio. The best thing
to do is test it on your baseline system and see how it sounds.
It would be nice if you could get better sound latency on faster systems by
using an adaptive buffer size (SDL could time the audio callback). This
way, you would get worse latencies on slower boxes, but no skips, and
get really low latencies on fast machines.
Would it be worth the effort?