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

[Rich Felker]

On Thu, May 03, 2007 at 11:32:06PM +0400, Vladimir Mosgalin wrote:
> Simple: you can't (and shouldn't) move everything to kernel. Audio
> requires pretty advanced stuff,

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

> like user-configurable resampling or
> stereo-to-surround mixing, or surround sound ajustements because user's
> audio system's setup isn't ideal. Transparent pcm surround-to-ac3
> encoding which should work for every app that tries to output
> multichannel sound (or simply if you want to make surround sound out of
> mp3 and then pass it as ac3 over digital interface to surround decoder,
> a feature that most people with multi-channel system want and which
> audio players don't support - for a reason). And to load plugins which
> do this, there must be some library which loads and configures them.
> 
> 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.

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

And no, it will never change. Only your pitiful irrelevant gnome
software will use gnome-vfs. Gnome is dead, thankfully.

> As for people who desperately want the last approach, there always is
> aoss wrapper, which transparently replaces open/read/ioctl functions by
> alsa calls. Much better than using kernel for that. Honestly, I don't
> know why are people complaining when they can use this. Just never try
> to use oss emulation layer in kernel and everything will be fine.

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.

> from modern audio systems, then tell it. Right now every alsa hater
> around here hasn't offered a solution yet.

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.

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

> Or you think that all applications should use kernel calls
> for opengl and opengl supporting "library" should be inside kernel? I
> don't honestly believe that anyone would want that. The thing is, modern
> audio is no simpler and just as well requires library approach, it's the
> least problematic solution.

Library approach is idiotic both in terms of design and performance.
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.

Rich