Hard disk recording. Audio/MIDI sequencers. "Cool" Windoze/Mac DAW style
user interfaces.
> >Agree, but if I can chose between unreliable 20 ms latency (at the very
> >least) and NO WAY to avoid crashing every now and then even if all
> >plug-ins are "bug free", and rock solid 3 ms latency (or whatever I
> >like) and the possibility of a crash when using a buggy plug-in, guess
> >where I'll go...
>
> and if i have to choose between RTL and running a Pulsar/Scope/Kyma
> under MacOS with the massive increase in processing power it would
> offer, i know what i'll do too ....
Yeah, Kyma/Capybara looks pretty nice. Can you send me a system? ;-)
Just 4 59309's in the basic configuration, though... Those DSPs are
efficient, but it wouldn't take a monster Alpha to beat that
performance. Might even be possible with Celerons or Xeons. (Well,
P-II/III too, but they have slower caches. The cache size doesn't help
much with small buffers/low latency.)
BTW, do you think you can expect a UN*X-like programming environment
when programming Kyma plug-ins?
> audio applications that require RTL don't interest me. its just not
> the kind of system i want to use. that might change over time.
Well, off course it all depends on what you want to do. I want rock
solid recording and editing with real time monitoring through the
virtual mixer. Preferably, everything should be running as long as the
audio apps are running. The feel of analog machines and dedicated boxes
with the advantages of having it all in the same environment.
> >What kind of system calls? What resources need to be hard real time in
> >addition to audio and MIDI ports?
>
> pthreads (perhaps not, if you use an event-driven model)
A pthreads API for RTL is in development. Parts of it have been usable
for quite a while.
> disk i/o
You don't really expect to do that in low latency hard real time, do
you!?
Besides, for anything more than one or two simultaneous tracks, you'll
need buffering in the order of seconds, unless you want to grab the
fastest drive money can buy, just to stress it to death on access
time... Seeks kill transfer rate very quickly.
It's just a matter of implementing a suitable set of asynchronous file
I/O functions... (Unless someone already did. I had it in mind, but
haven't got around to do it yet.)
> possibly shared memory stuff
Exists in RTL, altough I certainly don't like the current
implementation... There are patches for doing it in a nicer way, and I
expect this will become standard. (IMO, it HAS to be if RTL is ever
going into the main source tree.)
Anything else? :-)
//David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/