Not on a MIDI interface without hardware timing... And still, that
doesn't help if you want software MIDI routing.
> >> >"Cool" Windoze/Mac DAW style
> >>
> >> These all rely on external hardware if they do the job
> >> right.
> >
> >I disagree. It's just a matter of using the right kind of OS so that the
> >resources at hand can be used properly.
>
> you're not disagreeing with me :) the reason why the mac/windows DAW's
> use external hardware is because the OS they "run on" can't do the
> right thing.
I guees not then! :-) Those OSes are about as far as you can get from
the right thigh for native processing.
> but note: its possible on both those systems for an application to own
> the machine in the same sense that RTL does. despite this, nobody has
> yet managed to produce an audio application without external hardware
> for those OS's that doesn't have latency problems.
Not without a real time kernel that runs the whole system as a low
priority task. This is what RTLinux does, but as those solutions have to
do it without modifying the OS code, they have performance problems...
Besides, most of those solutions are VERY expensive.
> is it just that steinberg, creamware etc. are stupid,
Frankly, after seeing how some of them (mis)use hard drives and other
system resources, I begin to wonder...
> or is there something more
> important going on ? i mean, you really can hard real time as an
> application on the macos (even though its not a very friendly thing to
> do to the system), and yet ...
Obviously, there are problems that can't be solved without hacking true
real time support into the kernels. And besides, what about the drivers?
Unless the drivers run in RT context as well, you're screwed from the
start, no matter what you do. I think that's the whole problem. A real
time kernel won't help much.
> [ kyma ]
>
> >(What I meant was thinking about was actually the system that's running
> >on that external box for example. They all run some kind of OS, with
> >APIs and all.)
>
> i don't think that the Kyma/Capybara offers any API to the user.
Probably not, as it's a proprietary system. (You'll have to pay A LOT to
get the docs, if at all possible, if they're like the rest...) However,
I'm pretty sure their code doesn't run without any form of OS.
> >What would you have against Audiality (or RTL or whatever it will run on
> >in the end) as an end user? Apart from it all being open source, a dual
> >Alpha AXP or Xeon is a nice machine to play with when not using it for
> >recording... :-)
>
> mostly because quasimodo is designed to do the same things that you're
> talking about, its already written and running, and i'm committed (for
> now) to a non-RTL solution to the problems. quasimodo has already been
> ported to IRIX, a Solaris port is under way and a BeOS port is under
> discussion. for these reasons alone, reliance on RTL isn't very
> attractive.
Would pthreads do? That's the new API of RTL... I'm working on a method
to move drivers to an API that makes the usable both to Linux and RTL
using the same code. Victor Yodaiken is thinking about my suggestions...
Remains to see when and what, but something will be done here. Provided
your real time code is really designed by the rules, it may pretty soon
be a quite simple job porting stuff to RTL, and use the drivers just as
from user space.
//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/