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

[Rich Felker]

On Fri, May 04, 2007 at 05:03:04PM +0400, Vladimir Mosgalin wrote:
> > more than a way to handly my terminal windows. And mind you, most
> 
> What about browser,

None exists, they're all utter crap. For some tasks elinks is best
available, for others iceweasel is best available, but both (and all
others) royally suck.

> video player, audio player (I finally moved from
> mplayer to REAL gui audio player with nice library browser - I can say
> that it rocks..),

Thanks for showing your irrelevance again. If you like this gui crap
so much why not go troll their lists and get off ours??

FYI, MPlayer's sad gui is the only one I've tried which even
_attempts_ to display UTF-8 filenames correctly in the file/playlist
selector. So much for "advanced" gui players...

> IM client

Uhg, disgusting. Only viable IM client is bitlbee.

> and GUI editor?

What, n[ewb]edit? Sorry there are basically 2 editors, emacs and vi,
depending on your style/preference. Neither needs gui and both are
better without.

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

alsa-lib is simply not viable. OSS works fine regardless of whether
it's using oss/free drivers, alsa's "emulation" (a loaded, anti-OSS
word), or even 4front's proprietary crap.

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

No, I want features to be implemented _correctly_ or not at all.
Wrapper hacks where large parts of the functionality is missing are
not only non-functional; they introduce dependencies on huge
disgusting non-portable bloated libraries which are simply NOT AN
OPTION for any sane developer. On the other hand, if your system
supported the same access methods as gnome-vfs but via a plan9-like
filesystem namespace system with userspace-"bind", then the feature
could be added _transparently_ to all apps, without any increase to
their complexity or decrease to their functionality, and without
requiring that they use all that bloat on small systems where the
operator does not want such excess functionality.

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

This claim is unsubstantiated and false. The benefits are huge and
afaik there are no problems. A microkernel-based OS will be doing this
already.

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

This statement is blatently false. Audio processing is trivial. You
deliver samples to a device, in a format supported by the device, in
sequence and measure the current playback position in the buffer.
Nothing else is needed.

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

This is false. OSS API works for everybody just fine. Your problem
report is NOT a bug in OSS API but a bug in MPlayer, which you refuse
to report.

Rich