[linux-audio-dev] Old hat - comparison against windows

David Olofson david at olofson.net
Wed Jan 31 21:20:28 UTC 2007

On Wednesday 31 January 2007 21:45, Paul Davis wrote:
> On Wed, 2007-01-31 at 21:35 +0100, David Olofson wrote:
> > On Wednesday 31 January 2007 21:02, Michael Ost wrote:
> > [...]
> > > We have a 32 sample setting (.7 msecs) in Receptor which I have
> > > yet to see in a Windows driver. And it actually works with some
> > > plugins, even a large sampler like Synthogy Ivory --- if you
> > > don't try to play too many notes. %)
> > [...]
> > 
> > Have you considered RTAI/LXRT (microsecond scale hard real time in 
> > user space, sort of) for really insane latencies? ;-)
> there are no drivers for any audio interfaces that run in RTAI
> kernel space or in user space.
> theoretically, its cool an' all; practically speaking, i think its
> useless.

There are a few hacks for RTAI and/or RTLinux, actually, but AFAIK, 
nothing for any serious hardware... (I did one myself a few years 
ago, for RTLinux and AudioPCI cards, IIRC.)

Anyway, this is why I'm suggesting memory mapped mode. Instead of 
blocking in the driver calls, the audio thread would block on a 
periodic RTAI timer. The timer would be kept in sync with the 
hardware using an RTAI interrupt handler on the sound card IRQ, or 
(possibly simpler but less accurate) by a SCHED_FIFO thread that does 
talk to the driver.

It's pretty much the same method used by many PC game and demo sounds 
systems back in the DOS days. Instead of running the audio code in 
the interrupt context (if there was any!), it was run either in the 
video main loop or in some timer interrupt, while the DMA just kept 
looping over a buffer of 64 kB or so.

For running audio code under RTAI, it would probably be more 
appropriate to adjust the timer interval to keep the fragment size 
constant, but of course, the other way around may work too, depending 
on the plugin API and/or plugin implementations. You'd have to infer 
the timings either way, unless you can somehow read the current DMA 
position from the RTAI thread.

All that said, MIDI I/O would still be restricted to SCHED_FIFO 
scheduling. Missing MIDI deadlines is usually a lot less serious than 
missing audio deadlines, though, so it may not be a real issue.

//David Olofson - Programmer, Composer, Open Source Advocate

.-------  http://olofson.net - Games, SDL examples  -------.
|        http://zeespace.net - 2.5D rendering engine       |
|       http://audiality.org - Music/audio engine          |
|     http://eel.olofson.net - Real time scripting         |
'--  http://www.reologica.se - Rheology instrumentation  --'

More information about the Linux-audio-dev mailing list