Subject: Re: [alsa-devel] Re: [linux-audio-dev] Re: Toward a modularizationof audio component
From: Paul Davis (pbd_AT_Op.Net)
Date: Tue May 08 2001 - 00:48:38 EEST
>> 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:
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.
2) executing its plugins in a way that guarantees totally
synchronous operation.
3) facilitating data sharing amongst its plugins.
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.
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?
>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.
>> 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.
--p
This archive was generated by hypermail 2b28 : Tue May 08 2001 - 01:07:55 EEST