[music-dsp] DOS [or DOS mode] for low latency on PC?

David Olofson david at olofson.net
Tue Jan 6 10:36:01 EST 2004


On Tuesday 06 January 2004 18.33, augmentics wrote:
> Hi,
>
> 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:

	http://www.delorie.com/djgpp/

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 
Windows apps.


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.

	http://www.fsmlabs.com/products/products.html
	http://www.aero.polimi.it/~rtai/

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