Re: OSS vs ALSA flamewar

> The article seems to be full of misinformation about OSS. I don't know
> if there were already in the original presentation.

In the original LPC article, there was a link to the slides:
http://linuxplumbersconf.org/2009/program/

> "The OSS API requires any services (like data format conversion,
> routing, etc.) be implemented in the kernel."

This is perfectly true.

> Operations like data format conversions are no rocket science. They do
> require few extra CPU cycles but so what. The same number of CPU cycles
> will be spent even if the conversions are done in user space. The same
> is true with "routing". Routing/mixing is always based on some kernel
> level IPC mechanisms. In case of OSS these mechanisms are just hidden
> behind the kernel level audio API.

These are not arguments for putting the services in the kernel.

Davis' point was that the OSS API requires that _all_ services _must_
be in the kernel; it's not possible to add user-defined plugins without
going through some sort of loopback device.

> "It also encourages applications to do things that do not work well with
> other applications that are also trying to do some kind of audio task."
>
> Like what?

E.g., mmap(), which cannot be reasonably emulated; or mixer devices.

(The OSS v4 API is better in this regard, but developers cannot rely on
it as long as most implementations only offer v3.)

> "OSS applications are written such that they believe they completely
> control the hardware."
>
> This is complete BS.

Please watch your language. And your next sentence proves you false:

> Yes, there are many OSS applications that open /dev/mixer and
> peek/poke the global hardware level volume controls directly.
> However this is not the way how OSS is designed to be used.

Opening /dev/mixer and using it was the _only_ way how OSS was
designed to be used.

The /dev/something interface implies hardware control; even when
implementing 'virtual' devices, OSS has to use the same interface and
to pretend that it's a 'real' hardware device.

> OSS is perfectly adequate for needs of 99% of the audio programs.
> And I doubt ALSA is any better than OSS for the remaining 1% of
> applications (the laws of the nature are the same for both of them).

It's the OSS implementation that's lacking.
The percentage of programs that, for example,
* want to make use of the full capabilities of any modern device (like
   USB, HD-Audio, Bluetooth, Xonar), or
* want to use MIDI, or
* want to work correctly with suspend/resume, or
* must work on embedded architectures,
is way more than 1%. As long as these deficiencies exist, OSS will not
even be considered a theoretical replacement for ALSA.

> They are also required to move to RT kernels because
> ALSA and its followers depend on real time response times.

Please don't publish misinformation. Real-time response times are only
needed for real-time tasks like low-latency signal processing or
synthesizers, and this applies to any implementation, i.e., to both OSS
and ALSA.