Subject: Re: [linux-audio-dev] Re: timing issues in a client/server enviroment
From: Benno Senoner (sbenno_AT_gardena.net)
Date: la loka 09 1999 - 22:42:53 EDT
On Sun, 10 Oct 1999, David Olofson wrote:
> On Sun, 10 Oct 1999, Benno Senoner wrote:
> [...]
> > Quasimodo is a nice app with many functions, but it's still a
> > monolithic app, and my foobar wave editor can't use your 24db
> > lowpass filter with a simple API call.
>
> Actually, it could with the client/server/plug-in API I'm trying to
> describe, provided Quasimodo publishes it's plug-ins, accepts your
> connection request. But latency would of course increase with the
> number of client/server interface layers involved... And simple?
>
> > My idea is an engine ( userspace or RTLinux) , which handles the whole thing.
> > It could be similar to quasimodo, but in form of an engine, with flexible
> > routing, sample accurate evet processing, syncing etc.
>
> That can be done quite transparently through the API (client and
> plug-ins are very similar), but as I said, latency...
>
>
Seems that you are wrong about latency:
see my previous post ...
When I get some time I will implement my simple client/server model,
and run for example 5 clients which generate some audio (of course consuming
some CPU to simulate DSP computations) , with the server mixing together the
results. All with 2-3ms latency without dropouts (on the lowlatency kernel),
WHILE you are surfing the web.
:-)
Ok there is a limt of the number of simultaneous clients,
but most of time you will run out of CPU power due to dsp computations,
rather than due to scheduling overhead.
5 clients with 1ms fragments = 6% overhead
5 clients with 2ms fragments = 3% overhead
regards,
Benno.
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:13 EST