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

[Vladimir Mosgalin]

Hi Attila Kinali!

 On 2007.05.04 at 14:20:47 +0200, Attila Kinali wrote next:


Honestly, I don't know why you are discussing this with me. I completely
agree with most of your points...


> > In linux with alsa this all can be accomplished with much better
> > design, though it's true that user most likely will have to hack
> > through wikis and .asoundrc.. Well it will be fixed by some nice
> > guis in the future, right now it's the feature completeness that
> > matters. And alsa is the only way to get it.
> 
> Papering over design problems with a nice GUI is not a solution.

What's the problem with current state of .asoundrc?

> You might not know it, but there are stil people out there who
> like to use CLI for 99% of their work. Heck, X11 is for me nothing

So do I, just because it's faster.. But I still think it shouldn't be
the only way. Maybe best and nicest once you learned it, but not the
only one.

> more than a way to handly my terminal windows. And mind you, most

What about browser, video player, audio player (I finally moved from
mplayer to REAL gui audio player with nice library browser - I can say
that it rocks..), IM client and GUI editor?
I can agree that no other applications are strictly needed for the most
time.

> Plan9 might work or not, that's beyond the point. What the point
> is that ALSA has a lot of problems, and this fact isn't changed
> whether an other OS lives or dies.

So they should be solved. oss outside alsa on linux is basically dead,
and oss emulation in alsa has even more problems. No good way out.
Still, alsa used through alsa-lib seems to be the best way, compared to
others.

> Honestly, it makes life easier when you suddenly discover that you
> can just stick a few simple tools/libraries together to creat the
> functionality you want instead of useing a huge, monolitic, brittle

It's called -vfs for a reason... It uses user-defined handlers and so
on. Pipes can't do everything, sometimes dynamically loaded plugins or
similar approaches perform better.

I never said design is good, just idea is useful.

> So, you mean that a desktop application, that is feature complete
> but behaves totaly random is much more worth than an application
> that doesn't have all concievable features, but works 100% predicatble?

No one said about random. I just meant that of course ability to use
(vfs, plugins, pipe communications, etc) decreases predictability. But
it is still needed, comparing to very dumb, simple, 100% predictable
"open/read/write" interface with no additional features and no chance to
plug them in a sane way. That is what Rich, in my opinion, wants, and
where our stands are fundamentally different.

And my other point is that since you are going to use some (library, vfs
module, plugin, etc), you shouldn't access kernel calls just for the
sake of it, if they would be routed out of kernel right after that
anyway. This approach provides little benefits and a lot of problems.

And my third point is that audio requires processing that is complex
enough to use some kind of processing modules which should be
configurable and shouldn't be placed inside kernel.

That's all. Simple as that. I'm defending alsa library interface simply
because it fits into my ideas perfectly, and right now it's the ONLY way
to get working audio on linux for most people.

-- 

Vladimir