[LAD] SDL_mixer+LADSPA was:basic in-game audio synthesis api?

Justin Smith noisesmith at gmail.com
Mon Apr 6 15:00:56 UTC 2009

On Mon, Apr 6, 2009 at 8:44 AM, james morris <james at jwm-art.net> wrote:
> Hi,
> My experiment so far has yielded a WAV played via SDL_mixer and by
> registering a callback through Mix_RegisterEffect it is processed by the
> following LADSPA filters: 4x4allpass and Gverb.
> There might be some problems here though so I am asking if anybody can
> advise upon using SDL for audio.
> The problems with SDL_mixer are as follows:
> 1) The callback registered with Mix_RegisterEffect has a len parameter
> which is the length of the stream passed to the callback. It's value
> however seems mysteriously derived and it would be helpful to know in
> advance, it's precise value or expected ranges so I can create the IO
> buffers for the LADSPA effects only as large as they need be (rather
> than excessively large) before the fx call back is registered. ( is it
> always 1880 samples? )
> 2) Currently, I have a mono stream (i think, not entirely sure) and it
> goes to the FX callback, processed by 4x4allpass, and then by Gverb. I
> discard one of the output channels from Gverb because, what else can I
> do with it? Nothing AFAICT. (No buses :( )
> Are there solutions to this while still using SDL_mixer? Or should I
> write a custom mixer, (probably start coding from David Olofson's
> examples) ?
> Regards,
> James.
> On 3/4/2009, "Paul Davis" <paul at linuxaudiosystems.com> wrote:
>>On Fri, Apr 3, 2009 at 6:13 PM, james morris <james at jwm-art.net> wrote:
>>> Allowing the game to connect to JACK, and using LADSPA plugins for the
>>> effects was just one option I thought of, but it would be a little
>>> unusual for a game. But still, it might be interesting to try.
>>i wasn't suggesting JACK. just ladspa.
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev at lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

If I understand correctly, what you are talking about is the buffer
size. The tradeoffs with buffer size are that with a short buffer size
sonic events happen with a shorter latency (ie. if a "pew pew" sound
goes with the laser, a shorter buffer reduces the delay between the
user pushing the "fire" button and hearing the "pew pew" sound). If
the buffer is too short, your CPU usage will become too large, and
eventually you will probably get underruns in your output buffers,
creating skipping sounds or gaps in your audio. If the buffer size is
too large, you will have a sluggish feeling to the game and for faster
sequences of events the sounds won't quite go with the key presses and
images. Typically you want buffer sizes to be some power of two, or a
small multiple of a power of two.

More information about the Linux-audio-dev mailing list