Hannu Savolainen <hannu(a)opensound.com> writes:
[...]
The whole "OSS is depracated" issue is just
marketing propaganda used
to enforce application developers to jump to the ALSA API. Without this
developers would stick with OSS which is several magnitudes easier API
to use.
"Marketing propaganda?" 4Front Technologies is a company that
engages in the sale of software for profit. 4Front Technologies therefore
requires and presumably has a "market", people who pay them for their
products. I don't think the same situation exists for those
who develop ALSA.
OSS and ALSA are very different APIs. OSS is designed
for professional
software developers who should get their job done within tight
schedules. For this reason it has strong device abstraction. Everything
that could be automated has been automated. ALSA in turn is designed for
hackers (in the 1st place) who like to tweak every possible detail of
the hardware. This means there is practically no device abstraction and
the application should be more or less aware of the capabilities of the
hardware. Which API works better depends on the nature of the
application. This decision should not be driven by some political issues
as today.
So you say:
OSS: professional software developers
ALSO: hackers
How do others feel about this issue. Here is an example
from past discussion:
From: Paul Davis <pbd(a)Op.Net
Date: Tue, 03 Apr
2001 16:15:53 -0400
To: LAD <linux-audio-dev(a)ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] efficient non-blocking writes to /dev/dsp
Message-Id: <200104032013.QAA29210(a)renoir.op.net
In message <3ACA1FE4.B8E4EBE8(a)pp.htv.fi>you write:
>I would like to know what's wrong with
OSS API?
its impossible to use it in an efficient hardware-independent fashion,
because it has no concept of noninterleaved data streams. every time
you want to add a new concept to it, such as changing the sample clock
sync source, it can only be done via a new ioctl, which is rarely done
in a h/w independent fashion but instead as a card-specific hack. the
direct use of system calls means that its impossible to do the "grunt"
work of, say, resampling or sample bitwidth changes in user space -
this is all forced into the kernel. the system call-based API also
prevents the interposition of additional layers to provide
abstraction: the alsa-oss library, which is coming along very nicely
as a way to get *full* ALSA functionality even when using /dev/dsp
(rather than just OSS functionality via "emulation"), can only work by
using the LD_PRELOAD hack. there's no way to "bind" physical
connectors to channels in the OSS model: every OSS-based multichannel
driver so far has allowed wierd things like "well, this time when i
asked for 10 channels, I got channels 1-10, but the last time, it was
2-12". the kernel code has no interesting "midlevel" layer, forcing
many drivers to either offer limited functionality or duplicate code
from other drivers. need i go on ?
basically, the OSS API is based on h/w models from the SB16 era; ALSA
has successfully incorporated lots of lessons from devices like the
Hammerfall, the ice1712-based devices and others.
--p
[...]
My message is that if you prefer OSS over ALSA then
there is no need to
convert the code. OSS has been in the shadows during past couple of
years. However it will be back, We are working on an OSS version that
makes it possible to ALSA and OSS to co-exist.
Probably, the widespread adoption of ALSA by the linux community
gave you no choice but to develop such a version of OSS, no?
Oh, and you mis-spelled "4Front Technologies"