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

[Attila Kinali]

On Fri, 4 May 2007 01:58:27 +0400
Vladimir Mosgalin <mosgalin at VM10124.spb.edu> wrote:

> 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.
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
more than a way to handly my terminal windows. And mind you, most
unix guys i know work in a similar way i do, not that extreme, but
similar.

> > RTFM Plan 9. They had the correct way to do things like this. ALSA is
> > not the right way.
> 
> I know about plan 9, but we are on linux! If you don't like it, develop
> for plan9, who stops you? But don't suggest people to use plan9-like
> approach in application/libraries when kernel design was different, it
> just won't work. Also, I have a lot of doubts that plan9 approach will
> work; i.e. it will provide feature completeness for all cases in today's
> world of chaos without making developer's life a hell.

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.

> Honestly, it makes a life easier when you suddently discover that you
> can open/save files directly over ssh or smb or http in your favorite
> app. vim and bash and maybe something else have their own hacks for
> this, however centralized approach is much better. Maybe someday it
> could be done with fuse too (after all, it was done with avfs in the
> past), but right now gnome-vfs is one of the most working solutions.

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
block, that can only do the work it was designed for and cannot be
combined with anything else to extend this functionality.
_THAT_ is what the Rich and I (and a lot of other people) think is
against the unix way of things, where KISS is not just a phrase
but a life style.
 
> I don't really understand your problem. It may be harder to develop
> programs with use this, but it pays off when using them. Applications
> are made to be used, not to be developed. 

No, applications are not made to be used, they are made to solve
problems people like you and me have. And definitly not to restrict
their ability to solve those problems which the developer didn't
know about and couldnt imagine himself.

> However, when
> talking about desktop application, feature completeness worth much more
> than being predictable! 

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?

I really wonder how you are able to work with a computer.

> Even on unix. Because if I use unix, it doesn't
> mean that I want to lose features. No, I think that unix is the only
> system that can reach real feature completeness.

Noone said that you have to give up on features, the argument was
that doing things w/o or with the wrong design doesn't work out
in the long term. Featuritis like gnome and ALSA are celebrating
isn't the right way. It's exactly what we (and a lot of other
people out here) detest about windows.


> > And no, it will never change. Only your pitiful irrelevant gnome
> > software will use gnome-vfs. Gnome is dead, thankfully.
> 
> Eh.. huh? And I thought I was using it.. It's alive an kicking, and most
> apps around me use gnome too.

Yes, unfortunately, gnome is still alive.

> Actually, it's the only reason I'm using
> gnome desktop, for panels/window manager decorations/etc to have
> style consistency with all the apps that I use. Even though I absolutely
> hate nautilus and metacity and always used *step-like managers like
> afterstep and wmaker, I moved to gnome solely because 99% of apps that I
> used were using gtk or even gnome-libs.

Well, i have nothing against gnome, beside it being a total
mess, overengineered, bloat and slow. I deinstalled it from
all my computers quite some time ago, because it ate up too
much of my resources... way to much.
Unfortunately, gtk became so much gnome dependent these days
that it's hard to use even basic features of gtk-only apps
without installing gnome.

> > This is not acceptable at all. It's a hideous glibc-incestuous hack.
> > And it does NOT solve the fundmental flaw of ALSA that I commented on:
> > you cannot pass file descriptors according to genuine unix semantics.
> 
> The descriptors aren't suited for audio at all and should be deprecated.
> No point in discussing them! Just like you can't work with 3d
> acceleration using descriptors (no, open("/dev/dri/card0") doesn't
> count), you shouldn't work with audio using them.

Ok, please tell us why filedescriptors aren't suited for audio
at all and what better way is there.

 
> > Library approach is idiotic both in terms of design and performance.
> 
> So fuse-like callback from kernel to library and back to kernel is
> better in terms of design and performance, huh? 

Erm.. you brought up FUSE, not us. So don't use it like
we argued that FUSE is good design.

> (you still haven't
> offered anything better for all the problems I described, except for
> words "plan9". I'm interested in realistic solution that could be
> implemented in linux - the things I described aren't just for kicks,
> people really need them working at least /somehow/).

Plan9 API/System can be easily implemented in Linux. It's not so much
different than what Unix already has. Actualy, there is already
a project ongoing that tries to do exactly that.


			Attila Kinali

-- 
Praised are the Fountains of Shelieth, the silver harp of the waters,
But blest in my name forever this stream that stanched my thirst!
                         -- Deed of Morred