From: Kai Vehmanen <k@eca.cx>
To: alsa-devel@lists.sourceforge.net,
alsa-user@lists.sourceforge.net,
linux-audio-dev@music.columbia.edu
Subject: ALSA vs OSS/free
Date: Thu, 7 Mar 2002 15:55:31 +0200 (EET) [thread overview]
Message-ID: <a67s62$cjm$1@quimby2.netfonds.no> (raw)
Why is ALSA the better alternative? That's a question I've been asked
quite a few times recently. Below is a reply I just wrote to
ecasound-list. I'd be very interested in hearing your comments on this
issue. Have I missed some important points?
One thing that seems be causing a lot of confusion is performance and
latency comparisons. While ALSA provides many things that make it easier
for developers to reach better performance and low latency, similar
results can be achieved with well-written OSS drivers and applications.
Only in few specific cases (multichannel noninterleaved soundcards, etc)
ALSA provides a clear advantage. From marketing point of view I think it's
wise to acknowledge this. But there are other reasons why future looks
bright for ALSA:
--cut--
> 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.
--cut--
--
http://www.eca.cx
Audio software for Linux!
_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel
next reply other threads:[~2002-03-07 13:55 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-07 13:55 Kai Vehmanen [this message]
[not found] <Pine.LNX.4.44.0203071529210.923-100000@ecabase.localdomain>
2002-03-07 15:14 ` ALSA vs OSS/free James Courtier-Dutton
2002-03-07 15:31 ` Emmanuel Fleury
2002-03-07 16:28 ` Kai Vehmanen
2002-03-07 15:32 ` Thierry Vignaud
2002-03-07 21:59 ` stef
2002-03-07 22:00 ` Dan Hollis
-- strict thread matches above, loose matches on Subject: below --
2002-03-07 21:39 Kevin Conder
2002-03-08 20:21 Kevin Conder
2002-03-09 1:51 ` Daniel Caujolle-Bert
2002-03-08 23:35 ` Martijn Sipkema
2002-03-09 8:19 ` Jaroslav Kysela
2002-03-09 16:53 ` Jussi Laako
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='a67s62$cjm$1@quimby2.netfonds.no' \
--to=k@eca.cx \
--cc=alsa-devel@lists.sourceforge.net \
--cc=alsa-user@lists.sourceforge.net \
--cc=linux-audio-dev@music.columbia.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.