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

[Rich Felker]

On Fri, May 04, 2007 at 10:11:18PM +0400, Vladimir Mosgalin wrote:
> > No, all the DVD-sized videos I have don't need postprocessing because
> > the people who encoded them are competent.
> 
> You are too naive. I can't believe you. Don't you know how many ways to
> destroy video exist?

Of course. Apparently you don't know what my involvement in MPlayer
has been... I just don't download such crap, and certainly don't try
to repair bad source material in realtime as I watch it because that's
impossible.

> > If it runs nicely on old computers it will also run nicely (even
> > better) on new computers. The converse does not hold.
> 
> Unfortunately, this is wrong. If new computers are MUCH newer, this
> won't be the case. Think of surround sound as of upgrade of old stereo -
> you won't get surround just because you had working stereo. You won't
> get hardware 3d acceleration which is present on every computer nowadays
> when you run old software designed for software 3d rendering on some
> very old system.

But it still works just fine. Why should an app with nice software 3d
have to use your (*)#()$ opengl just because you have a new computer??

> You won't be able to run i386 binary on pure amd64
> system without multilib, and so on.

These are 2 different archs. Pretending they're the same is dumb. Of
course you can't run your i386 binary on sparc either, but you can if
you recompile the source.

> > It is MPlayer's bug! The application must choose and configure a
> > sample format, sample rate, etc. compatible with the device. If
> > MPlayer fails to do this then it's broken.
> 
> Why use oss if it implies such hard work on application? mplayer may be

It's not hard work. And you're only considering one special case,
playing preexisting audio samples. If your application is something
different, say a synthesizer like timidity or a sound engine for a
game or an emulator for an fm-synth type sound device, then your data
does not have a native format. Instead, you want to generate your
audio samples directly in whatever format/samplerate/etc. is native
for the output device to maximize quality and minimize the filtering
artifacts from resampling (which are horrible with ALSA's resampler,
btw...)

> > Curses windows/panels are disgusting bloat. It's like saving an image
> 
> But they work

Plenty of things that "work" are very bad ideas.

> > of your window contents in an XPixmap and blitting it on window-expose
> > events instead of processing the expose event and redrawing!
> 
> That's exactly how it works, at least sometimes! Ever heard of
> backingstore?

Yes, it's stupid. Big waste of resources and as I explained, no gain.
Your application already knows how to draw the display contents so it
can redraw them just as easily as it can copy a pixmap or make ncurses
redraw.

> > No, it supports fake bidi by outputting the characters in backwards
> > order. This is absolutely wrong and will break copy&paste as well as
> > breaking any correct terminal with implicit bidi (like mlterm) as the
> > default mode. It also has no hope of working with arabic shaping, only
> > with hebrew.
> > 
> > Bidi is a real mess and hell to support. Thankfully, implicit bidi
> > will work for _some_ apps, but it also breaks a lot of things. :(
> 
> I take your word for that, however apparently you haven't studied vim
> docs well enough. :help arabicshape and :help arabic.txt

This is even more atrocious; as far as I can tell, it's not even
writing the correct characters to the terminal but instead using the
"presentation forms" section of unicode which should never be used.

Rich