[SDL] audio documentation...

[David Olofson]

On Thursday 22 April 2004 00.52, Glenn Maynard wrote:
> On Wed, Apr 21, 2004 at 11:11:08PM +0200, David Olofson wrote:
> > No, without a recent (2.4+) kernel and/or lowlatency patches, it
> > can actually be *worse* than Windows, at least in terms of worst
> > case scheduling latency. (Average latency is pretty much
> > irrelevant to RT applications. It's usually in the µs range
> > regardless of OS anyway.)
>
> Huh?  Average scheduling latency in Linux 2.4 is at least 10ms.  If
> you set SCHED_RR, usleep() will give you smaller sleeps than that,
> but it's just busy looping--it isn't actually giving up any CPU (so
> you can't actually do this constantly, or you'll hang the system).
>
> Are you talking about something else when you say "scheduling
> latency"?

By "scheduling latency" I mean exactly that; the latency from the time 
a thread is supposed to be scheduled in, until it actually gets the 
CPU.

You're confusing it with the "jiffy" rate (the HZ #define), which 
defines the granularity of timesharing, timeouts, timers and whatnot 
in pre 2.6 Linux versions. (2.5+ has HZ set to 1000 or 1024 by 
default on most platforms including x86, and there are high 
resolution timers that do not depend on HZ.)

What I'm talking about is blocking in drivers for hardware that can 
generate IRQs on it's own. ISRs can trigger instant reschedules, so 
things become very different when you have a "real" time base - such 
as a sound card or a network interface - that drives your thread.


> > BTW, Audiality (the sound engine used in Kobo Deluxe) happily
> > runs with less than 10 ms latency even on standard 2.4 Linux
> > kernels, whereas I can't seem to get it to work at all with less
> > than ~70 ms latency on Win32. I'm still not totally sure why that
> > is, though; could be an Audiality/Win32 specific problem.
>
> The "prefetch size" (that is, the amount DirectSound tells you to
> write ahead in the buffer: the distance between the play and write
> cursors) is typically very large.  I think the only way to get
> around this right now is to use ASIO, or to use kernel streaming,
> which is 2k and XP- specific, documented as "probably won't work in
> future releases", and prevents other apps from playing sounds.

Using ASIO in a game? Well, why not - I guess there are quite a few 
gamers with ASIO supported sound cards these days. ;-)


> I think this is a limitation of DirectSound, and not something that
> drivers can fix.

Though it seems like *applications* can bypass the problem to some 
extent...

How come the "direct DMA mixing" approach still works, despite this 
limitation? (Doesn't Quake III do this on both Win32 and Linux?) One 
would think that if you can write to any place in the DMA buffer, it 
would just be a matter of scheduling, so you could just use a 1 kHz 
mmtimer or something.


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