[linux-audio-dev] Old hat - comparison against windows
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
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