[music-dsp] DOS [or DOS mode] for low latency on PC?
david at olofson.net
Tue Jan 6 10:36:01 EST 2004
On Tuesday 06 January 2004 18.33, augmentics wrote:
> As mentioned in the past, I need low latency between input and
> output for my processing algorithms.
> However Windows has horrible latency.
> Is it worth considering using a DOS PC - or "DOS mode" with 16-bit
> programs to access the raw
> soundcard hardware thus avoiding Windows? [There are several ASM
> drivers etc for SoundBlaster hardware
> on the Web]
DOS is little more than a "boot loader", so it's actually a perfect
environment for real time applications. There isn't much to get in
your way, and if you should have any trouble with DOS ISRs, you can
just disable them. (Remember to enable them again if you want to do
file I/O and stuff - and you should do something about the DOS time,
since it freezes if you stop the 18.2 Hz ISR.)
However, as an OS, it's a nasty environment to develop in. No
protected memory, no driver infrastructure, not much of anything
that's really a standard part of the "OS", and you can't safely do
file I/O and the like while running your RT stuff. (Though if you're
working on known hardware - ie turnkey systems - you can probably
just test it, and if it works, fine; use it.)
Most importantly, though, DOS runs in x86 Real Mode, which means you
have 16 bit addressing (640 kB memory through 64 kB "windows"). If
that's not enough, you need to add a DOS extender; ie a piece of code
that takes over the CPU and puts it in 16 or (preferably) 32 bit
Protected Mode. The problem with that is that you need to switch back
into Real Mode to run DOS calls, but OTOH, if you have your own
protected mode drivers for everything you need, that's not an issue.
Try DJGPP for a complete DOS protected mode C/C++ development system,
based on the GNU gcc compiler:
Finally, forget about "DOS mode". When running DOS apps, Windows stays
in the background with drivers and stuff running, so real time
performance is about as bad as (maybe worse than) that of native
Now, if you want a real OS as well as hard real time, you could try
RTLinux or RTAI; two ways of adding real time support to Linux. You
get latencies as close to the hardware limit as an RTOS can get, and
you can still have the Linux system running in the background.
Unfortunately, the standard Linux drivers are not hard real time
capable, so you'll still have to use your own drivers in most cases.
However, in the case of soundcards, you can probably get away with
setting the card up in DMA mode and hook into the soundcard's IRQ
with an RTL/RTAI ISR. That way, you're using the standard Linux
(OSS/Free or ALSA) driver to set up the audio I/O, but once it's
running, you're only using the IRQ and the DMA buffers. You just put
your RT code in an RTL/RTAI periodic (timer driven) thread, and
adjust the timing based on the IRQs, so you can update N fragments of
the DMA buffer per soundcard IRQ.
Oh, and keep in mind that some soundcards generate IRQs for MIDI I/O
and other stuff as well, so you may have to check what the IRQs are
actually about. Look at the OSS/Free or ALSA driver code to find out
how to do that. Note that if you can't check the status without
clearing it, you'll have to move the actual h/w status check into
your RTL/RTAI ISR.
//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 music-dsp