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

[Vladimir Mosgalin]

Hi Reimar Döffinger!

 On 2007.05.03 at 23:03:33 +0200, Reimar Döffinger wrote next:

> > 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 are you asking me? I don't like the fact that alsa has problems with
it, but what can I do about it? Well maybe help with documenting it, but
I have more interesting stuff to do.. Honestly, I don't think anybody
would mind if you will step in and offer documenting that API. It's just
that it hasn't been done yet. It's bad, but well.. you can't forget the
fact that application still manage to work somehow. Maybe if kernel api
was clear from the beginning some application would have used it and it
would gave problems to users later.

> Why is it necessary to make it impossible to use that direct kernel API

Because it would interfere with user's alsa setup. Because working with
some cards could be hard. VERY hard.

> for all those where this "pretty advanced stuff" only causes problems
> like it did for over a year for MPlayer?

Well, let's forget about that. Maybe alsa was not mature enough. As a
matter or fact, it still isn't. But there is nothing better,
unfortunately.

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

That's what I'm trying to do ;) Well, not that I'm trying very hard,
I just couldn't ignore some points which I consider totally wrong.

> 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

Oh no, read what I've written to Rich about server applications and
stuff. Don't forget about gnome- part. The current approach should only
be used with some gui desktop apps, something much better is needed as
general approach.

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

Sure. However, on desktop sometimes it's worth sacrifying it for
features.

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

No, answer is that you are getting extra userspace->kernel and
kernel->userspace switches and increase audio-related userspace/kernel
bandwith by 3 times when kernel uses library that you should've used
instead..

And if you think about app->alsa->jack->alsa->kernel setup that I use,
imagine what happens..

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

Yep. Still, no other solutions to make old oss apps behave nicely. Well,
there is also oss2jack, which uses fusd..

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

unfortunately yes, fglrx module size is >750kb, still "dri" fglrx part
and gl library are much bigger (10 mb and 1 mb). So most work is done in
library..

-- 

Vladimir