Subject: [linux-audio-dev] Re: [alsa-devel] laaga, round 2
From: Abramo Bagnara (abramo_AT_alsa-project.org)
Date: Tue May 08 2001 - 16:50:19 EEST
Paul Davis wrote:
>
> i grow tired of debating with abramo (as i'm sure he does with me). so
You're very intuitive this morning ;-) I had already begun to write a
message like your with subject "Modular sound: a chimera?", but after
that I've been distracted by a XFS on LVM on RAID installation...
I'll integrate your message.
> i am going to try to summarize what i think are the basics, as best as
> i can from my highly non-objective point of view.
>
> AES worldview
>
> The server presents an abstraction of an audio interface to
> dynamically loaded (in-process) clients. That abstraction consists of
> some number of "channels" for capture, and some number for
> playback. Each channel can be used as a data source or data
> destination by using functions provided by the server. All data read
> from or written to a channel is in mono IEEE 32 bit float format. The
> server "executes" plugins on a periodic basis by calling a function
> that they provide, passing it a single argument, the number of frames
> of audio that they should process/generate. Some of the channels
> provided by the server function as shared data areas allowing plugins
> to read and write each others audio data if they so choose.
Here between I insert my section:
Objectives:
-----------
- integration/interconnection of audio components and audio applications
- reuse of audio components
- API number reduction
- lowest latency and maximum efficiency
- write applications that treat *all* audio components as black boxes
with well known API
> alsa-lib worldview
>
> Everything is an ALSA PCM stream. Components that have streams
Not so strong ;-) I'd say that "every audio component is a PCM stream"
> available for capture are called "producers"; those with streams
> available for playback are called consumers. When connecting two
> components together, it is necessary to ensure that their parameters
> match or that some converter component is inserted between them. Each
> component has its own set of pre-conditions to be satisfied before it
> is possible to read/write audio data from/to it. a component may
Wonderful, you've understand me perfectly.
> represent a real hardware audio interface or a pure software model, or
> some combination of both. an organizing object called an engine is
> responsible for ensuring that calls to check the pre-conditions for
> each component are made. components access each other directly, using
> calls from the ALSA PCM API to transfer data.
The preconditions/parameters matching is done hierarchily: the engine
does this step only with its directly connected components.
>
> [ not clear: what drives the engine?
> can a component be a producer and a consumer? ]
The engine loop is driven by their consumers/producers ready condition.
(yes, multiple conditions).
Often this correspond to HW interrupts, but this is not necessarily
true.
I've still a residual doubt about engine: it's better to have multiple
engines? (Remember I call engine something that elaborate/copy data from
a set of producer to a set of consumer) But in this case how to know
which engine need to be called first? Perhaps an engine method.
I've further details about my model that you can find interesting (or
obvious who knows):
- communication between components is achieved using ring buffers in
shared memory
- 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.)
> I've tried to be as fair as I can in presenting these summaries. What
> do you think?
That you've done a very good work in resuming, I'm impressed...
BTW Can we cease to use LAAGA acronyms or better too, can you confirm
that LAAGA is something related to objectives I've written above?
My interest is only a modular architecture aimed to object (plugins,
gui, scopes, components, etc.) reusal and well defined connectivity.
If LAAGA is not this, I've missed a good occasion to close my mouth.
-- 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 - 17:33:22 EEST