Subject: Re: [alsa-devel] Re: [linux-audio-dev] Re: Toward a modularizationof audio component
From: Abramo Bagnara (abramo_AT_alsa-project.org)
Date: Tue May 08 2001 - 01:29:40 EEST
Paul Davis wrote:
>
> >> 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.
>
> well, then we're talking about something *completely* different.
>
> LAAGA was proposed by Kai, somewhat based on my AES system. it doesn't
> meet the description you propose at all.
> in it, an engine is the core application. it has 3 responsibilities:
same in my model
>
> 1) "masking" all access to the audio hardware via
> an abstraction: X channels of capture, Y channels of
> playback, each channel consists of 32 bit floating point
> data, no parameters of any kind.
here I disagree, to have parameters may be very useful for negotiate
audio components communication details
> 2) executing its plugins in a way that guarantees totally
> synchronous operation.
same in my model
> 3) facilitating data sharing amongst its plugins.
This is too generic for me, I don't understand what you mean.
> it has no concept of "consumers" and "producers". the fact that the
> current implementation of AES happens to use the
> {request,release}_channel() model is merely to optimize certain
> aspects of data transfer to/from the audio interface.
>
> ardour is in no way an engine application. to use your terms, its a
> producer *and* a consumer. in my terms, its a plugin to an "engine",
> which it relies upon as an interface to a set of channels that carry
> floating point data, and as the driving force of its operation (i.e by
> calling the relevant process() function).
>
> you seem to have a completely different model here.
You've seen the diagram, so only you can tell this for sure.
> a key feature of the AES/LAAGA model is that the audio h/w *drives*
> the engine (this is a requirement for fulfilling (2) above). in your
> model, it seems that audio h/w capture is controlled by a producer and
> audio h/w playback is controlled by a consumer; its hard for me to see
> how this could work. do you designate a particular producer as
> "special", and somehow have the engine do its thing when that producer
> says it has data ready? what if that producer is not a h/w producer at
> all?
for each producer
producer->wait()
producer->get()
elaborate()
for each consumer
consumer->wait()
consumer->put()
It's so easy (and it solves the problem you've encountered recently with
ardour about playback/capture ready condition drift)
> >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.
>
> because for systems with interesting characteristics (e.g. ardour,
> evo, ecasound, etc.) the audio data (almost) never exists in
> interleaved format, is (almost) never processed in interleaved format
> and (almost) never should be in interleaved format unless and until
> the hardware in use requires it.
>
> i consider the interleaved mode of operation a historical accident
> that it would be wise to abandon. its less efficient for
> high-performance systems, and trivial in terms of cost for standard
> "consumer" applications that route audio to a couple of channels.
This is a not proved argument. If I think for a plugin that swap L/R
channel on a stereo stream it's much faster with interleaved format.
However this is not the point (interleaved vs non-interleaved): I've
asked why you're interested to access channel separately. We've
discussed this recently about alsa-lib PCM API and I think you've
verified that there is no need for it and probably this make to lose
some efficiency.
> >> 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?
>
> as indicated above, ardour is both a producer (when it supplies data
> to a channel, such as from a diskstream) and a consumer (when it
> collects data from a diskstream or a channel). your model suggests
> that it would be necessary to divide it into two pieces. this is would
> be a sort of reductio ad absurdum, IMHO.
To divide ardour? Absolutely not: in my mind ardour is a complex engine
that drive data from a set of producer to a set of consumer.
You seem to not understand that in my model ardour itself it's neither a
producer nor a consumer: it's an application that act as a bridge
between producers (diskstream or channels) and consumer (diskstream or
channels).
-- 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 - 02:12:28 EEST