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

[Rich Felker]

On Fri, May 04, 2007 at 01:58:27AM +0400, Vladimir Mosgalin wrote:
> Hi Rich Felker!
> 
>  On 2007.05.03 at 16:27:35 -0400, Rich Felker wrote next:
> 
> > Requires is a very strong word here. I think the correct way of saying
> > this is "special interests require these features, at the expense of
> > ordinary non-special-interest folks".
> 
> No. In this case, yours interests are special; regular people around
> want to easily utilize surround capabilities, plug in webcams/usb

Surround sound is already a special-interest for audiophile idiots who
can't count the number of ears they have and who flunked linear
algebra...

> soundcard, drivers for which embeddes all these features. Awful design,
> a lot of problems, but at least it mostly works. In linux with alsa this
> all can be accomplished with much better design, though it's true that

Worse design than windows....

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

It makes both developers' and users' lives simple and clean. The
ALSA/GNU/Linux approach is about letting implementation complexity
approach infinity to satisfy lame users who should just go buy a Mac.
It's not sustainable from the development standpoint (precludes new
people getting involved and learning about how the system works, how
to hack it, etc.) or from a hardware requirements standpoint.

> > abomination and impose it upon us all. Go rot in hell.
> 
> Thanks! ;) Maybe I'll get the chance to meet you there in person..

If I believed in it maybe...

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

Lots of things that "make life easy" are bad. That's the road to hell.
:)

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

A system with 10-levels-deep lib dependency trees, hundreds of megs of
libs, 5-second load times due to symbol resolving, etc. is NOT VIABLE
FOR USERS. Maybe for you stupid "buy a new computer every week"
windows kids with 100x-overspec toys, but that's not what the majority
of the world has, only a vocal minority of "enthusiasts". Like I said,
special interests.

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

I've only encountered one application I wanted to use which had gnome
dependencies, even on Debian which is notorious for making things
depend on optional gnome functionality. Gnome is mostly a collection
of toy "accessories" applets and ugly "desktop integration" glue, not
useful applications.

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

You provided no reasoning here; thus I'm going to ignore your stupid
claim.

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

And why not??

> > other preferences but I expect them to respect mine as well and not
> > throw around insults and (what's worse) actively attack and try to
> > harm my ability to use the system by breaking things in the name of
> > "progress".
> 
> OK. Think it over again. Right now, alsa is the only way of getting all
> the features I described and most compatible and least problematic
> interface to use on linux.

I agree proprietary 4front crap is not viable, but there's no reason
the OSS api can't support the things you want, and in fact I think
4front folks have proven that it can...

> People won't use commercial oss drivers. Oss/free in kernel is dying,
> almost dead.  Alsa-oss emulation in kernel doesn't provide necessary
> features and hardly even works (for example, it doesn't work at all for
> my usb soundcard - mplayer only prints 
> "[AO OSS] Can't set audio device /dev/dsp1 to s16le output, trying s16le...\n"

Then specify the right format settings for your device in your MPlayer
config file, or file a proper bug report or send a patch that makes it
try the right sequence of fallback formats...

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

Keep calling it fuse-like; this is historical revisionism and probably
not quite correct since I don't think fuse can implement devices, only
ordinary-file-like semantics. The correct way of saying it is
plan9-like or perhaps even hurd-like.

> better in terms of design and performance, huh? (you still haven't

Yes.

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

My advice for the time being is to use a sound server if you want to
share and abstract the sound device, just like you use a display
server/windowing system if you want to share and abstract the video
and input devices. The good long-term development direction is
something like plan9.

> Why do you think inventors of gl and opengl (on unix!!) have choosen a
> library approach then?

OpenGL was invented by idiots at SGI, not by Ken Thompson... There's
been plenty of idiotic ideas built on top of Unix that don't adhere to
unix philosophy, on both Linux and proprietary unices.

> I don't think you understand how high-level some opengl directives are
> (library + driver part) and how much work they do comparing to what
> accelerator gets on input..

I'm quite aware.

> Think of a very low-level assembler
> language, very much like the one CPU gets on input. Your idea basically
> means turning libc and all libraries in the system into a big database
> full of assembler/bytecode/machine code instructions.
> 
> You won't be able to draw anything nice this way, just like you can't
> design a complex system in assembler.

You can and many many people did, before the days of people using
wasteful 3ghz crap that's 100x faster and more power-hungry than
anyone needs. (Yes old machines were even more power-hungry due to
primitive tech, but if technology had evolved in the responsible way
we should be using 30mhz machines with 0.5watt power usage instead of
3ghz machines with 300watt power usage.)

> The software you are using
> wouldn't be able to exist with such approach.

For drawing something complex, you're totally free to use or implement
libraries built upon the lowest-level primitives. That doesn't mean
that everyone should be confined to the same _BAD_ library. But this
has gotten totally OT from ALSA by now...

Rich