Subject: Re: [ecasound] cvs not compiling for me
From: Kai Vehmanen (k_AT_eca.cx)
Date: Thu Mar 07 2002 - 15:29:14 EET
On Wed, 6 Mar 2002, Bill Allen wrote:
> ./configure --disable-alsa
[...]
> c++ -DHAVE_CONFIG_H -I. -I. -I../.. -I. -I../.. -I../../libecasound
> -I../../kvutils -I/usr/include/kde/artsc -O2 -D_REENTRANT -DNDEBUG
> -ffast-math -fstrict-aliasing -funroll-loops -DENABLE_DBC
> -Wp,-MD,.deps/audioio_alsa.pp -c audioio_alsa.cpp -fPIC -DPIC -o
> .libs/audioio_alsa.lo
> audioio_alsa.cpp:27:28: alsa/asoundlib.h: No such file or directory
Oops, sorry. This is fixed in CVS.
> Have I got something wrong, or does ecasound require alsa at this point. I
> see that jack does require alsa and the development of ecasound seems to
> be moving toward using jackd.
No. The only things ecasound requires are libc (with posix threads) and
standard C++ runtime enviroment. Everything else is optional.
This is one of the reasons why ecasound has its own plugin architecture.
This way the the main libecasound library doesn't have to be linked
against ALSA, aRts, JACK, libaudiofile, etc external libraries. Only
direct external dependency is linking against ncurses/termcap. If this is
not wanted, the --disable-ncurses must be given at compile time. And even
in this case, it's the ecasound executable, not libecasound, that requires
ncurses.
Avoiding unnecessary dependencies is very high on my priority list.
> Philosophically (and technically) speaking, are there real advantages for
> me to install alsa (other than the above) when OSS/free works for me? I
If OSS works for you, then no. ALSA's primary advantages are:
[common]
- separation of kernel and user-space code [all]
- ALSA library can provide more functionality to
applications (format conversions, sharing soundcard
resources, dsp plugins)
- benefits ALSA-native apps
[alsa-kernel/alsa-driver]
- better driver architecture
- more shared code between drivers for
different soundcards
-> fixes and improvements to common code affect all
drivers
-> drivers behave more uniformly
- benefits both ALSA-native and apps using OSS-emulation
- support for pro-level soundcards without performance problems
- for instance handling devices that only support
noninterleaved buffer layout
- befefits ALSA-native apps (and in some cases also
apps using OSS-emulation)
[alsa-lib]
- better API for applications [alsa-lib]
- more flexible configuration of various parameters
- well-designed API for acquiring realtime status
information (for various playback/capture
synchronation purposes)
- benefits ALSA-native apps
So shortly put, ALSA provides a better framework for writing drivers and
for developing audio applications. When comparing OSS/Free and ALSA from
an end-user's point of view, it comes down to the quality of the drivers
for the soundcard type in question, and the specific applications that are
used. Some OSS/Free drivers are very good and support all OSS API
features. If this is the case and all apps seem to work ok, you don't have
much to gain from switching to ALSA... yet.
But because of the abovementioned reasons, over time ALSA drivers and
applications will become better than OSS versions. I think this is
inevitable.
-- http://www.eca.cx Audio software for Linux!-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request_AT_wakkanet.fi>.
This archive was generated by hypermail 2b28 : Thu Mar 07 2002 - 15:20:56 EET