Subject: Re: [ecasound] C-API
From: Kai Vehmanen (k@eca.cx)
Date: Sun Dec 03 2000 - 21:29:06 EET
On Fri, 1 Dec 2000, Luke Tindall wrote:
> I have some time for hacking next week and I'm going to have a go at doing
> a mixer app with spin buttons & sliders for the ia-mode commands eg panning,
> ampiltude etc. What header files are installed so I can link to libecasound?
> Can I have a quick C example.
Ok, hmm, first you need to decide how you want to use ecasound. The four
alternatives are:
1. Forking ecasound - [all languages]
Fork ecasound on the background (in interactive mode) and send ia-mode to
it using a standard pipe. This is what Heteca and Eco do, and also the
most stable alternative (no need to link against libecasound nor use its
header files). Also, you can use just about any language.
2. Ecasound Control Interface - [C++, C, Python]
This should be a tempting alternative, but unfortunately, is not yet ready
for use. The first implementations will be in C++, C and Python. Provides
slightly more functionality than (1), and is more convenient to use. On
the bad side, well, doesn't exist yet. :)
3. ECA_CONTROL - [C++]
Use the ECA_CONTROL class (#include <ecasound/eca-control.h>). This is
what (2) is based on. ECA_CONTROL is a huge interface class that accepts
ia-mode commands, and offers lots of functions for controlling the whole
library. Best examples are the utils in ecatools directory (most of them
are just a couple screenfuls of code). Also, qtecasound and ecawave
heavily use ECA_CONTROL. The idea here is that I can mess
freely with other classes, but ECA_CONTROL interface stays relatively
stable. This way I don't constantly have to be updating
qtecasound/ecawave/ecatools/etc.
4. Use libecasound classes directly - [C++]
#include <ecasound/eca-something.h>. If there's nothing else to try,
you can always use ecasound classes directly (for instance, MP3FILE,
WAVEFILE, OSS_DEVICE, etc). This is flexible, but you have to closely
follow the libecasound ChangeLog file.
So that's about it. I guess the important fact to be aware of is that
libecasound is _not_ a static library, or doesn't even try to be. I do
follow a very strict libtool versioning policy, so that no binary nor
source level changes (that affect incompatibility) are done without
increasing the libtool version. But there will still be changes. So from
this point of view, (1) is the bext, while (4) is most dependent on
libecasound development.
-- . http://www.eca.cx ... [ audio software for linux ] /\ . . http://www.eca.cx/aivastus ... [ aivastus net radio ] /\ .-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request@wakkanet.fi>.
This archive was generated by hypermail 2b28 : Sun Dec 03 2000 - 20:49:27 EET