Subject: [linux-audio-dev] Re: [alsa-devel] Re: laaga, round 2
From: Kai Vehmanen (kaiv_AT_wakkanet.fi)
Date: Tue May 08 2001 - 18:57:46 EEST
On Tue, 8 May 2001, Abramo Bagnara wrote:
>> alsa-lib worldview
> - communication between components is achieved using ring buffers in
> shared memory
Now I think this is the central point. The whole point of LAAGA is running
all rt-critical code in _one_ thread. This means _all_ audio components.
Other tasks like...
> - GUIs runs in separate process or thread and communicate with engines
> using a shared memory area. Engines *never* will stop waiting for GUI
> (I've designed a model to do this without mutex, for both direction, by
> example visual scopes and controls)
> - disk access is done by separated threads using large intermediate
> buffers. Sometime the engine will need to wait r/w completion, but this
> is likely a symptom of a severe problem (too small buffers, disk access
> too slow, bad OS behaviour, etc.)
... are run in separate threads/processes just like you describe above,
but _all_ audio code runs in one thread.
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.
> 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.
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.
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. ;)
-- http://www.eca.cx Audio software for Linux!
This archive was generated by hypermail 2b28 : Tue May 08 2001 - 18:43:34 EEST