[MPlayer-dev-eng] [patch] prefer ALSA over OSS

[Vladimir Mosgalin]

Hi Reimar Döffinger!

 On 2007.05.03 at 20:25:22 +0200, Reimar Döffinger wrote next:

> Well, what exactly is it missing (from an API standpoint, not
> implementation), and more importantly what of that could not have been
> adding by improving it e.g. adding a few ioctls?
> Why is it necessary to _require_ a library for doing audio, even more so

Simple: you can't (and shouldn't) move everything to kernel. Audio
requires pretty advanced stuff, like user-configurable resampling or
stereo-to-surround mixing, or surround sound ajustements because user's
audio system's setup isn't ideal. Transparent pcm surround-to-ac3
encoding which should work for every app that tries to output
multichannel sound (or simply if you want to make surround sound out of
mp3 and then pass it as ac3 over digital interface to surround decoder,
a feature that most people with multi-channel system want and which
audio players don't support - for a reason). And to load plugins which
do this, there must be some library which loads and configures them.

All this stuff has to be there and has to be transparent from
application (well, maybe not completely transparent - application always
can use different alsa devices, but at least transparent to dump apps
which use "default" device). Do you really think it all belongs to
kernel? AC3 encoder? Resampler options and surround coefficients
configurable via /proc ? Alsa plugins as kernel modules? Brr..

Or you just want to use kernel api at any cost, even if these
open/write/ioctls would then be routed out of kernel to some FUSE-like
sound processing library? Kernel is pretty busy with other stuff, to do
such stupid things. Well, right now fuse exists, because people are
conservative and still want to use old-fashioned direct open/read/etc
calls instead of gnome-vfs interface or something, but someday, this
will have to change, too ;).

As for people who desperately want the last approach, there always is
aoss wrapper, which transparently replaces open/read/ioctl functions by
alsa calls. Much better than using kernel for that. Honestly, I don't
know why are people complaining when they can use this. Just never try
to use oss emulation layer in kernel and everything will be fine.

If you know any other solution where you can have oss (or oss-like)
calls and still transparently accomplish everything that people want
from modern audio systems, then tell it. Right now every alsa hater
around here hasn't offered a solution yet. Think again about comparison
of modern 3d graphics with monochrome (or character-based) terminal,
of course you can say that "resampling/surround/encoding/etc belong only
to app and should never be done outside of it", but it just means that
you are returning to days where 3d rendering could only be done in
software, but video card was just a pure framebuffer with a few controls
like page switching to you. Yeah, it was so simple.. Want to return to
these days? Or you think that all applications should use kernel calls
for opengl and opengl supporting "library" should be inside kernel? I
don't honestly believe that anyone would want that. The thing is, modern
audio is no simpler and just as well requires library approach, it's the
least problematic solution.

You simply will never win as long as you are ignoring these problems.

-- 

Vladimir