All of lore.kernel.org
 help / color / mirror / Atom feed
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

             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.