Re: [linux-audio-dev] OSS will be back

Hannu Savolainen <hannu@email-addr-hidden> 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@email-addr-hidden>
  Date: Tue, 03 Apr 2001 16:15:53 -0400
  To: LAD <linux-audio-dev@email-addr-hidden>
  Subject: Re: [linux-audio-dev] efficient non-blocking writes to /dev/dsp
  Message-Id: <200104032013.QAA29210@email-addr-hidden>

  In message <3ACA1FE4.B8E4EBE8@email-addr-hiddenyou 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"
Received on Fri Nov 3 00:15:04 2006