[linux-audio-dev] OSS will be back
jurek at cs.uchicago.edu
Thu Nov 2 20:01:58 UTC 2006
Hannu Savolainen <hannu at 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
How do others feel about this issue. Here is an example
from past discussion:
From: Paul Davis <pbd at Op.Net>
Date: Tue, 03 Apr 2001 16:15:53 -0400
To: LAD <linux-audio-dev at ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] efficient non-blocking writes to /dev/dsp
Message-Id: <200104032013.QAA29210 at renoir.op.net>
In message <3ACA1FE4.B8E4EBE8 at 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.
> 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"
More information about the Linux-audio-dev