Subject: Re: [linux-audio-dev] matrix model vs. memory
From: Abramo Bagnara (abramo_AT_alsa-project.org)
Date: Mon May 21 2001 - 13:42:18 EEST
Jörn Nettingsmeier wrote:
>
> Abramo Bagnara wrote:
> >
> > Tom Pincince wrote:
> > >
> > > > Yes, but I don't have excluded the possibility to have buffer sharing.
> > > > Of course this is feasible only for a subclass of static gain matrix.
> > >
> > > It may be useful to consider the percentage of connections that are
> > > static gain. If this number is very small then the efficiency loss is
> > > worth the simplicity of having only one kind of connection. In
> > > situations where the user is using just a simple app, such as for
> > > playback, the efficiency may go down by a large percentage, but the
> > > total demand on the system is so low in this case that preserving
> > > efficiency is not an issue. So if we look at a complex studio setup,
> >
> > Don't try to use a crystal ball when designing an API. It's dangerous
> > and I'm sure to be able to find a counter example for each imposed
> > limitation. (And I'm also sure that to tell you them is perfectly
> > useless).
> >
> > What we need to do is a complete API with no efficiency drawbacks and no
> > needless complexity.
> >
> > To have something that work well for an application subset, but it's not
> > appropriate for another is a symptom of bad design.
>
> abramo,
> might this be yet another incarnation of the age-old "make it work,
> then make it better" vs. "make it better first" battle ?
>
> btw, i think it's not very sensible to accuse a studio tech like tom
> of "looking into a crystal ball" when he gives a concise analysis of
> signal flow and gain handling in an *actual* studio.
Don't misunderstand me, Tom analysis is very useful to have a minimal
*subset* of what we need. But its messagge seemed to me oriented to give
a superset, i.e. "no support for what it's out of there".
Note also that I don't want a perfect API, I want an extensible API (not
an *extended* API, an *extensible* one)
> i might be missing a point here, but i'd rather have a limited api
> *today* than a perfect api in the future, where
Ok for a limited/partially implemented API, but not for a *limiting*
one.
That's whole my point.
-- 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 21 2001 - 13:59:38 EEST