[SDL] audio documentation...

[David Olofson]

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 <
> 10?

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 
threads.

(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 
about XP.

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 ---