Re: [linux-audio-dev] Realtime restrictions when running multiple audio apps .. Was: Re: disksampler ...

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Realtime restrictions when running multiple audio apps .. Was: Re: disksampler ...
From: David Olofson (david_AT_gardena.net)
Date: Mon Jul 17 2000 - 13:16:30 EEST


On Sun, 16 Jul 2000, Benno Senoner wrote:
> Including object oriented features, and higher level features, we will not be
> able to deliver such low latencies.

It's not impossible to do OO RT, but why use overkill tools when
they'll only make things more complicated?

"Complicated" is *why* Benno is right here; the complexity of most
OO languages can easily hide unobvious latency issues behind "nice"
interfaces. Not that OO is useless for RT programming, but the C++
newbie should *definitely* not try to code his/her first RT app in
that language!

> And the pro-audio folks simply do not want to give up these achievable
> latencies. Latency is everything for live stuff.

Well, for jamming in the studio as well, actually. Trackers on the
Amiga were OK, because you could treat them like real instruments
when improvising with the samples, but I have yet to see a newer
tracker that doesn't have *serious* latency problems... Even FT2/DOS
seems to have somewhat high latency, unless you're using a GUS card
(which is basically a hardware sampler).

> So I know Stephan is asking why we start from scratch instead of building on
> aRts, but I agree with Juhana that only by using a very small audio "kernel",
> we will able to achieve our goal.

Yes, think "kernel" or "scheduler" rather than "engine" or "host".
There are pretty big differences, actually.

> The problem of this model is that it forces you to design the apps in a
> different way and it is not as straightforward as using the normal programming
> model.

For RT processing with streaming and sample accurate
synchronization, I think it actually looks more straightforward than
the alternatives I can imagine.

> Do how does aRts fit in this scheme ?
> I don't know currently , perhaps we will find a solution to integrate the
> audio "minikernel" with aRts.

Well, if this is a prototype and an API + programming model in
development, aRts might become an alternative solution for setting up
a system that supports the new API + programming model?

> One drawback is that if one plugin crashes , then the whole audio
> apps will be compromized. (eg if cubase crashes , disksampler will exit/crash
> too).
> WE can live with this because the crash of an application will compromize
> our audio work anyway (what if you are mastering your song, and the
> sampler crashes (eg which provides the drumset) , but a 2nd softsynth is still
> alive ? Will the song be usable ? No, thus the above problems are only solvable
> by writing correct/bug-free applications.

Yeah, a system can never be more reliable than it's weakest
component. It can, however get on it's feet again very reliably and
quickly if there's a solid foundation and a nice design behind it.
(As opposed to certain Other Systems that tend to risk severe HD
data corruption on a daily basis... Ahem.)

Actually, some (usually embeded) systems clean up and restart so
quickly that no one will ever notice that anything went wrong!
Unfortunately, it's probably next to impossible to do that with our
applications, unless we run multiple systems in parallel, but at
least, we'll never have to reboot to get the applications up running
again. :-)

//David

.- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
`------------> http://www.linuxdj.com/mucos -' | Open Source Advocate |
.- A u d i a l i t y ------------------------. | Singer |
| Rock Solid Low Latency Signal Processing | | Songwriter |
`---> http://www.angelfire.com/or/audiality -' `-> david_AT_linuxdj.com -'


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Mon Jul 17 2000 - 15:52:27 EEST