Hi All!
Please bear with me, I’m one of those bloody rookies…
I wrote a simple 2d arcade game using SDL and wanted to add sound support
yesterday. I used SDL_mixer (to be able to play mods in the back) and
everything went fine, but all wav sounds I play are approximately 200-300
ms too late. I know that PC systems with normal sound cards feature a
latency, so, this came not totally unexpected, but my questions now are:
Actually, they don’t; it’s just a matter of Windows not being capable of real
time scheduling, crappy drivers, and some times flawed application
implementations.
The latency is not the symptom of any of this, but rather the side effect of
trying to avoid drop-outs and other audio glitches; inreased buffering. It’s
up to the application to decide how many and how big buffers to have between
the code and the driver, and drivers rarely add significantly to that
buffering.
- Is my way of thought correct, in other words, is this a latency I have
to cope with or did I do something wrong, maybe ?
I’m not sure how SDL figures out how many buffres to use, but it should use 3
or more buffers for optimum reliability at high CPU load. However, games
rarely use more than a fraction of the CPU power for audio, so even 2 buffers
should be ok. (More buffers at the same total buffer size allow for more
scheduling jitter and DSP load fluctuations without drop outs.)
Anyway, the “samples” field in the SDL_AudioSpec that you pass to
SDL_OpenAudio() specifies the desired buffer size. Set this to a lower value
to decrease latency.
- What do the great wizards of gaming do to prevent this kind of thing ?
(I can’t really play a sound 200 ms BEFORE my player collects an extra,
because he might very well decide not to collect it in that time)…
The same applies to real time music synthesis (ie soft synths controlled by
external MIDI sources), and can be dealt with by
1) moving the audio code into a kernel driver,
2) using a shared memory driver and mixing ahead when evenst occur, or
3) using on operating system suitable for real time multimedia.
As 1) is a h*ll of a hack to do (at least on Windows), compromizes the
stability and security of the system and still doesn’t really make that big a
difference, especially not to games, I’m not going to discuss it further here.
- is not an option if you’re concerned with user base for games. If you want
to sell lots of copies, you still have to do a Windows release and/or perhaps
one or more consoles. If that’s not an issue, try BeOS or Linux/lowlatency.
BeOS allows you to do 3 ms latency with acceptable reliability with good
audio cards, and Linux/lowlatency lets you go down to 2 ms with practically
any sound card, and is rock solid.
If you’re stuck with Windows, MacOS and/or mainstream Linux kernels, 2) is
the way to low latency audio. However, I don’t think SDL supports it, so
you’ll have to use the underlying APIs directly…
I can expand on the above if you’re interested and want very low latency
without drop-outs on the entire audio stream, but I think you should be able
to get away with the SDL API and lower buffering. Try lower values and see if
it gets good enough without frequent drop-outs. (An occasional drop-out at
latencies below some 100-200 ms can never be avoided with less than an OS
with proper real time scheduling.)
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |
--------------------------------------> david at linuxdj.com -'On Tuesday 13 February 2001 12:20, Jan Krutisch wrote: