Subject: Re: [linux-audio-dev] Re: Pragmatic comparison of approaches to audio engine
From: Steve Harris (S.W.Harris_AT_ecs.soton.ac.uk)
Date: Mon May 14 2001 - 17:12:52 EEST
On Mon, May 14, 2001 at 06:54:07AM -0400, Paul Davis wrote:
> >Ok, I've finished a new version of ctx.c that complete the picture
> >adding multi process approach.
>
> this looks pretty good. my only point of contention would be the
> rather small memory footprint of the the process, which i'm not
> totally sure is realistic for actual components in a system like
> this. If you look at the numbers for lat_ctx, the cost of the
> inter-process context switch rises fairly significantly as the
> process' memory footprint increases.
Also there is the issue of priorities, will the system be workable if the
processes are all shed_fifo? The current single process implementations do
seem to be very stable w.r.t. xruns.
> If the memory footprint doesn't have a dramatic effect, I'd be willing
> to consider the multi-process model since processor speeds are already
> in the 1.5GHz range. If it does, then I think that a single-threaded
> design is the only option for a low-latency real-time situation.
It seems to me that if we go for the single process model then in the
short term we have nice lowlatency, fast apps, but in a few years we may
be suffering from useful, but not 100% stable systems. Whereas if we go
for the multi process model we will have systems that are (relativly) high
latency in the short term, but in the long term they will be down the the
<3 ms mark and stable.
Bit of a rock and a hard place.
Can we wrapper the API with library calls, macros or whatever so
that with just a recompile apps can move from one model to another? I
don't want to loose the ability to do low latency work with my current
machine, but I also don't want to shoot myself in the foot by backing a
model which might make future software unreliable.
- Steve
This archive was generated by hypermail 2b28 : Mon May 14 2001 - 16:31:06 EEST