Subject: Re: [alsa-devel] Re: [linux-audio-dev] Re: Toward a modularizationof audio component
From: Abramo Bagnara (abramo_AT_alsa-project.org)
Date: Mon May 07 2001 - 19:04:51 EEST
Paul Davis wrote:
>
> >I try to redraw my example using your graphic conventions:
> >
> >
> > GUI visual scope
> >+------||-----------||-------------------------------------+
> >| audio_producer1 ----\ |
> >| audio_producer2 -----\ /-- audio_consumer1 |
> >| > engine < |
> >| audio_producer3 -----/ \-- audio_consumerN |
> >| audio_producerN ----/ |
> >+-------||-----------------------------------||------------+
> > appl file writer thread
> >
> >Now, let's zoom on audio_producer1:
> >
> > GUI visual scope
> > || ||
> > ------------------||--------||-------
> > || ||
> > HW capture -> plugin -> meter ->
>
> First problem: "HW capture"
>
> The entire point of the LAAGA API is to remove such
> concepts from the things that use LAAGA. The LAAGA
> server is the only thing with access to the H/W, and the
> only thing that cares about hardware.
I don't think that *one* thing called LAAGA server exist.
In my model an engine is an arbitrary application that obtain audio data
from a set of producers (that transparently may obtain data from other
producers) elaborate it and then send it to a set of consumers (that
transparently may send data to other consumers).
ardour is an engine application. aplay would be another, etc.
Before to ask to ourself if current object is an audio component or an
audio engine we need to ask ourselves a question: can this be written as
an audio component?
By example mpg123 is an audio producer, not an engine. Of course we'll
have a simple engine that load an audio consumer and an audio producer
and send produced audio to the consumer. ladcat is a good name? ;-)
>
> Now, this can be avoided by saying "oh, by "HW capture"
> I just mean something like "read_from_channel (chn, ...)",
> and thats OK.
>
> Except that ALSA has no component in its API that looks
> anything like this, and if it did, its semantics would
> be rather hard to specify, since it would presumably
> have to work both within a system like LAAGA and without.
I'd like to understand why you want hard separate the audio data in
channels and obtain the data separated. This is less efficient IMO and
that apart simply I don't see why.
An HW PCM stream is definitely a perfectly sane producer (capture) or
consumer (playback) in my model.
> >Zoom on audio_producer2:
> >
> > GUI
> > ||
> > ------------||----
> > ||
> > file -> plugin ->
>
> if i understand this correctly, it would violate the rule on no
> blocking operations in server plugins.
I'm aware, I was drawing what is feasible, not what's sensible ;-)
File reader thread GUI
|| ||
-------||------------||-
|| ||
pcm_file_reader -> plugin
is the correct thing.
> >Zoom on audio_consumer1:
> >
> > -> pcm_file_writer -> HW playback
> > ||
> >-----------||-------------------------
> > ||
> > File writer thread
>
> same problems as with "HW capture", but substitute
> "write_to_channel".
>
> Finally, i would echo Jim's broader point about this model of
> "producers and consumers". Most of the kinds of things that would be
> attached to this server would be both producers and consumers, and its
> hard for me to see how (or even why) to use this kind of model if that
> kind of plugin dominates.
Component reusal I guess, but I'm not sure to understand your point, can
you make me a the simplest example that show the flaw of this model?
-- 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 : Mon May 07 2001 - 19:30:30 EEST