Subject: [linux-audio-dev] Re: [alsa-devel] Re: laaga, round 2
From: Abramo Bagnara (abramo_AT_alsa-project.org)
Date: Tue May 08 2001 - 18:34:21 EEST
Kai Vehmanen wrote:
>
> Now ok, I admit that it doesn't help if we keep repeating this again and
> again... it's true that real-life performance is what counts in the end.
> It very well might be that your idea of using shared memory between
> multiple audio components is good enough, but at the moment there's no
> proof of this available. On the other hand, LAAGA is already implemented
> and works remarkably well --> AES&Ardour!!! Ie. the one-thread-only
> approach _works_. So until other mechanisms are proven to work this well,
> one-threaded model is the one I'm interested in.
It seems you're missing that I propose shared memory ring buffers for
both one-thread-only approach and multi thread/processes.
> > My interest is only a modular architecture aimed to object (plugins,
> > gui, scopes, components, etc.) reusal and well defined connectivity.
>
> Btw; I want to emphasize that we also need the kind of
> component-to-component communication you are talking about. It's almost
> certain that only a small percent of apps will ever be converted into
> LAAGA (or whatever) plugins.
Here I disagree: if we'll develop a general enough architecture the
advantages will be so many that every professional level application
will be converted.
Note also that we're (with humbleness) designing the future and if the
architecture will have a good design we'll condition the structure of
future application/components.
We need an architecture that move interest of developers from to write
an application to write a component, this is IMO a fundamental thing.
Often I feel that Paul is too focused on a single
problem/application/solution I think that we need to think in a long
sighted way, a more general way.
> I've tried to think about easy ways of converting existing OSS/ALSA apps
> into LAAGA plugins, but now I'm fairly that there isn't any such solution.
> The whole point is that you have to take advantage of the plugin-model -
> ie. you have to convert your app's audio generating part into a single
> callback function. This is not necessarily easy. Of course it would be
> possible to write some middleware, but you wouldn't get any of the LAAGA
> benefits. Ie. if you just replace snd_pcm_write() with some new LAAGA
> middleware API function that writes to shared memory, you'll lose the
> low-latency charateristics.
This would work enough well for consumer level applications if we design
our model to include them (via loopback server and shm client).
Note also that the extra cost of N threading/process approach may be
teoretically reduced to 2*(N-1) context switches every elapsed period
and probably this may be an acceptable cost in a lot of real life
situation.
> but like I described in my earlier mail, there are plenty of
> not-so-hard-realtime needs for connecting audio apps. Recording
> application output, generic disk reader/writer components, multiplexing
> input/output, etc, etc are possible uses for a non-plugin based audio
> framework (like aserver, aRts, etc). Of course, if it turns out that
> shared-memory (or even UNIX sockets), is just as fast as our plugin
> approach, well, then we have been wrong with Paul. ;)
-- Abramo Bagnara mailto:abramo_AT_alsa-project.orgOpera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy
ALSA project http://www.alsa-project.org It sounds good!
This archive was generated by hypermail 2b28 : Tue May 08 2001 - 19:03:41 EEST