[SDL] audio documentation...
david at olofson.net
Thu Apr 22 11:13:06 PDT 2004
On Thursday 22 April 2004 19.05, Neil Bradley wrote:
> > If the main loop just plain hogs the CPU constantly (as it does
> > if you run full speed with no retrace sync),
> These old games have fixed frame rates, so I have a callback timer
> that locks me to the specific framerate the game used. Much better
> than things like MAME that will sit at 100% even for extremely
> simple emulations and drain your laptop's battery. ;-)
Yeah... I added a frame rate throttling feature to Kobo Deluxe
specifically to avoid that. :-)
> > At least, this works very reliably on Linux, so messing with
> > thread priorities is just pointless - unless you go all the way
> > and switch to real time scheduling. (RT scheduling on Linux
> > totally bypasses the timesharing rules. The CPU is yours until
> > you explicitly let it go.)
> In other words, cooperative multitasking? Circa Windows 3.1 MacOS <
Not quite. Unlike those environments, Linux RT threads still have
blocking I/O calls and the usual threading stuff - just like any
other threads. The difference is that SCHED_FIFO threads have fixed
priority, and can only be preempted by higher priority SCHED_FIFO
(BTW, SCHED_FIFO has been around for ages. The lowlatency patches just
transform it from a system stability hazard into a really useful
feature for serious multimedia.)
> > > Most people don't know what "audio buffer size" even means, let
> > > alone how to set it. And I'm not sure what you mean by "very
> > > high", but 1/30th of a second has always worked for me.
> > "Very high" would be well over 50 ms, but I don't think you
> > should need that on any system if everything's working properly.
> > It depends a bit on the game and the sounds, though.
> Hm... at my buffer settings it's sitting at around 23ms and seems
> to work reliably/fine.
Nice. I guess I'm just using too much CPU time for the SDL buffer
configuration. Double buffering is suboptimal when it comes to
handling CPU load in the audio thread with significant scheduling
jitter. Using three or more buffers allows you to use more CPU time
and/or handle more jitter, even if you change the buffer size to get
the same total latency.
Unfortunately, some studio sound card drivers and some APIs are
hardwired for exactly two buffers. :-/
> > Well, that would be Kernel Streams and similar "hacks", I
> > guess... Still, that alone doesn't solve the problem, since
> > there's still tons of stuff (ISRs of other drivers, among other
> > things) that can get in the way.
> It's unlikely that another ISR would take 10s of milliseconds to
> execute, though, but it's not out of the question for various
> threads to do so.
Well, I dunno what's happening in there, but it seems to be impossible
to guarantee solid RT scheduling if you sub ms worst case latency,
even in kernel space... On NT, it wasn't even possible with third
party RT kernels. (Some people tried *really* hard to run hard RT
industrial control stuff on NT, but it's just not possible.) In
Win2k, you can at least get firm RT (ie "rock solid most of the time,
but don't let it fly a plane") with decent h/w and some luck. Dunno
I'd say "too little, too late". I gave up on Windows years ago because
of these issues (long before people started abusing DSound and
messing with Win98 internals in softsynths), and I've *still* not
heard anything from Windows audio hackers that indicates MS have
really fixed it. External DSP solutions are still the way to go for
rock solid low latency audio processing.
Either way, I'm not going back even if Windows eventually gets *real*
RT support - though that's mostly for other reasons, totally
unrelated to low latency audio. ;-)
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---
More information about the SDL