Subject: Re: [linux-audio-dev] join LAD! (fwd)
From: Kai Vehmanen (kaiv_AT_wakkanet.fi)
Date: pe helmi 25 2000 - 08:49:55 EST
On Thu, 24 Feb 2000, Paul Barton-Davis wrote:
> however, libraries only work well when they do well defined
> tasks. even if at some point, the tasks that an "audio toolbox"
> library has to do become clear and undisputable, we are definitely
> *not* at that point yet. it doesn't help to argue this point by
Design of modular audio systems seems to be quite a challenge.
As an example, here's a few (C/C++) approaches for implementing
inputs-operators-outputs abstraction:
1. The traditional low-level style. You have functions that take
a pointer to array of floats/ints, output pointer and sample count.
This is, of course, very efficient and is used in many projects.
2. Data abstraction. For instance in ecasound, all audio data is
stored into abstract sample-buffer objects. The whole system
is based on passing these buffers around the system (or better,
pointers to these objects are passed around).
3. Flow-centric abstraction. SPKit is a good example of this. The
whole system is based around class hierarchies that can be connected
to each other. Both inputs/outputs and operators are parts
of the same system.
I've had to transfer algorithms between these systems, and it's
not easy (lot's of work, if nothing else). For instance, if I want
to use an external plugin in ecasound, that requires a pointer to
array of floats, it requires additional copying of data, and this
is of course inefficient (what if there are hundreds of operators).
If we used a general flow-system, we'd had to code our applications
to use the same design-model or otherwise it would be inefficient.
-- Kai Vehmanen <kaiv_AT_wakkanet.fi> -------- CS, University of Turku, Finland . http://www.wakkanet.fi/ecasound/ - linux multitrack audio processing . http://www.wakkanet.fi/sculpscape/ - ambient-idm-rock-... mp3/ra/wav
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:27 EST