[SDL] Questions about SDL 1.3 and audio callback function

Jared Maddox absinthdraco at gmail.com
Sat Dec 25 23:27:35 PST 2010

> Date: Sat, 25 Dec 2010 02:11:48 +0000
> From: "Fox, Paul A." <FOXPA1 at GCC.EDU>
> To: "sdl at lists.libsdl.org" <sdl at lists.libsdl.org>
> Subject: [SDL] Questions about SDL 1.3 and audio callback function
> Message-ID: <D8668E5A61A9F349A3E2CCDC50A0EEA501268F at EXSMBX01.GCC.edu>
> Content-Type: text/plain; charset="us-ascii"


>  Firstly, how much execution time is reasonable for the
> audio callback function? If it buffers ahead a fair ways,
> I could call my audio decoder and populate the buffer
> directly from it within the callback function, but if it is
> expected that the callback will return quickly, I need to
> decode the audio somewhere else.

The execution time should always be a (fairly small) fraction of the
buffer duration.

Buffer duration in seconds = audio sample number / samples per second.
I'm pretty sure that you want this value to be some fraction of a
second for your particular app, instead of having a big buffer (see
below for why), but I'm equally certain you don't actually get to
choose what it is on some platforms.

I'd suggest having a dedicated thread do the actual decoding, store
the data into a temporary buffer, and have the callback read from that

>   Also, I want to be able to sync video to the audio clock,
> essentially delaying or skipping frames based on audio
> timing (again, to minimize latency). It seems reasonable
> that I should get the timestamp of the audio segment being
> passed in the callback function, and update some global
> variable, so the video (probably running in a different
> thread, once I get that figured out) can know when to
> refresh, or skip a frame. However, this again depends on
> how much buffering is going to be done within SDL/the
> audio device.

I'm not seeing any mention in the documentation of a timestamp being
passed to the callback, so I'm guessing you intend to provide that

As I best recall, the callback is NORMALLY only used when the buffer
that was previously provided starts being played (so, when buffer 1
starts playing, SDL will request buffer 2), but I recommend providing
some way for the user to adjust the video/audio sync offset/speed
anyways, since this can potentially be an OS-specific trait.

Regardless, I believe that you can't get progress information that's
more accurate than the duration of the buffer without specialty
hardware (the actual playback is often done by a cheap chip with 1+
analog outputs, and the things apparently often don't provide progress

More information about the SDL mailing list