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

[Reimar Döffinger]

Hello,
On Thu, May 03, 2007 at 11:32:06PM +0400, Vladimir Mosgalin wrote:
>  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.

So you need a library on top of the kernel API. No problem there. But
why is it necessary for that to use an obscure undocumented kernel API?
Why is it necessary to make it impossible to use that direct kernel API
for all those where this "pretty advanced stuff" only causes problems
like it did for over a year for MPlayer?

[...]
> Alsa plugins as kernel modules? Brr..

This has been done, or at least attempted, anyway, and it is horrible.

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

As an additional feature, why not? But it's not necessary if you
convince everyone to use that library that does all the advanced stuff.

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

Ah, so in the future gnome-vfs will use gnome-vfs to load gnome-vfs to
load gnome-vfs to.... after the kernel has used gnome-vfs to load
itself, right? Anyway, just replace the libc and most applications will
use gnome-vfs. But probably most would find out that they would not want
it, because the amount of code involved will _always_ lead to a much
higher number of bugs.
And concerning your "kernel is pretty busy with other stuff", well, how
about userspace being pretty busy without handling lots of ALSA code and
its filters for some? Why aren't these people even considered? (I know
the answer, they probably don't really care about sound so haven't been
writing any code and have no say. Which I consider fair, but that
doesn't make ALSA better here).

> As for people who desperately want the last approach, there always is
> aoss wrapper, which transparently replaces open/read/ioctl functions by
> alsa calls.
[...]

aoss is even more code, thus even buggier and slower.


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

Hmm.. ALSA lib on top of OSS backend? I don't know if this is
possible/what is missing in OSS but if wanted I guess you could both
extend OSS and/or have ALSA as a frontend to jack with OSS backend etc.
pp.
Each of these ways
1) simple things could be done simple and with little code
2) applications can use the level of abstraction that actually fits
their needs

[...]
> Or you think that all applications should use kernel calls
> for opengl and opengl supporting "library" should be inside kernel?

For all I know that's what NVidia and ATI are doing (at least they are
doing a lot in the kernel), so some are obviously thinking like that.
But obviously that is not what I want, kernel should expose the hardware
as directly and simple as possible.
And those who want should have a nice library available.
ALSA approach would be to remove /dev/fb, /dev/tty*, all consoles, 
make it impossible to use svgalib and vidix, hide the documentation
for all X functions and only leave OpenGL for applications to use.

Greetings,
Reimar Döffinger