LPC: The past, present, and future of Linux audio [LWN.net]

LPC: The past, present, and future of Linux audio

Posted Oct 18, 2009 11:52 UTC (Sun) by hannu (guest, #61409)
Parent article: LPC: The past, present, and future of Linux audio

The article seems to be full of misinformation about OSS. I don't know
if there were already in the original presentation. Hopefully not since
both Paul and Lennart have been around long enough time to learn the
basic facts.

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

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.

"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?

History of the anti-OSS campaign is based on this kind of silly
arguments that don't make any sense. Any API can be misused by
developers who don't care to read the documentation. This is true with
OSS, ALSA, Jack, PulseAudio as well as every single API in the software
industry.

"OSS applications are written such that they believe they completely
control the hardware."

This is complete BS. 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.

"Because of that, Davis was quite clear that the 'OSS API must die'. He
noted that Fedora no longer supports OSS and was hopeful that other
distributions would follow that lead."

This is intentional misinformation. There is very loud group of audio
(API) developers who insist that OSS must die based on arguments like
the above. This started about 10 years ago but OSS is still used by
large number of applications. Why? Simply because 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).

The big reason to kill OSS is not OSS itself. If OSS is really that bad
then it should have died spontaneously years ago. However it's still
hanging around. The real reason is a design mistake made by developers
of ALSA . It prevents ALSA from co-existing with OSS. This mistake
prevents ALSA from becoming successful as long as there are any
applications using the OSS API. To be specific this "mistake" was ALSA's
decision to implement their own kernel level drivers instead of just
implementing alsa-lib on top of OSS drivers. Another fundamental mistake
was dmix that separates software mixing conceptually from hardware
mixing. For dmix to work it's necessary that all applications go through
ALSA's library interface even they don't need any of ALSA's "advanced"
features. Without these fundamental design flaws both OSS and ALSA could
exist at the same time.

As a workaround it's mandatory that linux distributions like Fedora drop
OSS prematurely. They are also required to move to RT kernels because
ALSA and its followers depend on real time response times. Only after
that the emperor can finally get his new clothes.

to post comments

Re: OSS vs ALSA flamewar

Posted Oct 19, 2009 12:34 UTC (Mon) by cladisch (✭ supporter ✭, #50193) [Link]

> 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.

LPC: The past, present, and future of Linux audio

Posted Oct 20, 2009 9:38 UTC (Tue) by njs (subscriber, #40338) [Link] (1 responses)

I have no technical opinion on sound APIs, though it's obvious that ALSA is a total mess. But this cult-like thing around OSS is just *bizarre*, and plenty to convince me that ALSA is a better choice.

LPC: The past, present, and future of Linux audio

Posted Oct 20, 2009 17:43 UTC (Tue) by bronson (subscriber, #4806) [Link]

njs, Hannu's the guy who wrote OSS, took it private to try to extract money, and is now acting surprised that nobody's interested in using it (even the BSDs, which are OSSish by legacy but still have rewrites: http://wiki.freebsd.org/Sound )

He can safely be ignored.

That said, I do wish ALSA wasn't such a mess. I'm hoping GStreamer and Phonon become the de facto application APIs so app writers don't have to care about the slipperly kernel sound APIs anymore.