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

[Vladimir Mosgalin]

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
"speakers" (with built-in very dumb soundcard chips) and listen mp3 so
that sound comes not only from front channels. I don't know about the
world you live in, maybe unix programmers usually don't desire this, but
most people in the world think of home computer as as kind of
entertainment center and use windows, which easily does all this and
other things I described - considering they've got a "proper" expensive
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
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.

> > All this stuff has to be there and has to be transparent from
> > application (well, maybe not completely transparent - application always
> > can use different alsa devices, but at least transparent to dump apps
> > which use "default" device). Do you really think it all belongs to
> > kernel? AC3 encoder? Resampler options and surround coefficients
> > configurable via /proc ? Alsa plugins as kernel modules? Brr..
> 
> 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.

> > 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 ;).
> 
> Uhg, at least you revealed your true colors as one of the unix-haters
> who's trying to destroy standards and inject this gnome-vfs
> abomination and impose it upon us all. Go rot in hell.

Thanks! ;) Maybe I'll get the chance to meet you there in person..

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.

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. Honestly, I understand your
point when speaking about network servers and similar stuff, some of
them don't even need concepts of "locale other than C, language other
than english and time other than GMT", because being 100% stable and
predictable is much useful than having features for them. However, when
talking about desktop application, feature completeness worth much more
than being predictable! 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.

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

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

> That's because most of us don't think there's any problem to be
> solved. We have sane requirements, not your nasty special-interest
> requirements.

You seem to have a problem with alsa. You, not me. I don't. When sane
alsa interface is used, users get all the features and it doesn't break
their setup (also they get rid of nasty "application mplayer uses
deprecated interface" messages). What about solving your problem (i.e.
reason why alsa doesn't work, or doesn't work as good as alsa oss
emulation/real oss)? I don't see any problem when mplayer uses alsa.
(mine uses jack, FYI, but I used alsa output with alsa->jack alsa
routing plugin when I had problems with mplayer's jack driver).

> > Think again about comparison of modern 3d graphics with monochrome
> > (or character-based) terminal, of course you can say that
> > "resampling/surround/encoding/etc belong only to app and should
> > never be done outside of it", but it just means that you are
> > returning to days where 3d rendering could only be done in software,
> > but video card was just a pure framebuffer with a few controls like
> > page switching to you. Yeah, it was so simple.. Want to return to
> > these days?
> 
> Return? Who said anything about return? That's where I've lived quite
> happily since the beginning. I acknowledge that other people have

I figured as much.

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

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"
indefinitely). Frankly, right now there are simple no other choices than
regular alsa interface. Well there are some for you, for your computer,
but not for most peoples' computers. Hardware mixing, random sample
rates etc. - modern soundcards have lost these "features" for good.
Instead, they have other features, like multichannel, ac3/dts
passthrough and other stuff (which mostly cannot be used properly with
oss). You can think whatever you want, but you won't be able to go to
the shop and buy a soundcard which supports hardware mixing for example,
unless it's an old and low quality creative card which mostly aren't
even developed anymore.. And without hardware mixing, using oss
emulation in alsa is a good way to block sound for user. Honestly, I'm
tired of these examples. The fact that something works for you doesn't
mean that it works for everybody and even that it will work for most
people (even when taking only linux users into account).

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

> The correct approach to 3d (and graphics acceleration in general) is
> to define, via a standardized file format analogous to terminfo
> database for terminals, the accelerator functions available and how to
> construct the commands to write to the device. OpenGL can be
> implemented on top of this, but so can lots of other interfaces not
> limited by the horrible misdesign of OpenGL.

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

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.. 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. The software you are using
wouldn't be able to exist with such approach.

-- 

Vladimir