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

Attila Kinali attila at kinali.ch
Fri May 4 13:48:50 CEST 2007


On Thu, 3 May 2007 16:13:15 -0400
Rich Felker <dalias at aerifal.cx> wrote:

> On Thu, May 03, 2007 at 08:42:18PM +0200, Nicolas George wrote:
> > Le quartidi 14 floréal, an CCXV, Michael Niedermayer a écrit :
> > <snip>
> > 
> > See my other mail about your other points.
> > 
> > > ALSA is like forcing all image/video access in linux through libsdl and to be
> > > honest the mere thought scares me
> > 
> > Somewhere, all image/video access in Linux goes through a common piece of
> > code: that is called the system. The system need to be good: the API must be
> > agreeable enough for developers, but there must be enough room for the user
> > to configure and override things.
> > 
> > For example, as a X11 user, I would hate that an application I want to use
> > would be SVGAlib only. That thought scares me much more than the thought
> > that everything should go through SDL.

Well, have you ever worked with SDL? Have you ever
tried to play anything using SDL in real time?
SDL might be nice if you want to quickly code something
to test whether your idea works without caring too much
about the lowlevel systems. But if you want to do real
stuff you have to get your hands dirty.

It is not by chance, that the first device MPlayer ever
supported was mga_vid. Both X11 and SDL were already available
at that time. IIRC even XVideo was around back then. But,
neither of the alternatives could give smooth playback with
the PCs available back then.
But yes, X11, Xv and sdl were the next output devices
supported by MPlayer, but only _additionally_ to mga_vid,
not replacing it (unlike what people want with OSS vs ALSA).
Thus mga_vid is not only still used, but still maintained,
even though the hardware it needs is more than just ancient.
 
> This is all aside from the point. Surely an application wanting to
> reach the largest possible audience might support both X and one or
> more direct graphics targets, like MPlayer does. The question at stake
> here is whether these others are available at all.
> 
> Also, ALSA is not at all analogous to X. X is well-designed and has
> thus withstood the test of time, and most importantly it's documented.

No, xlib is far from being well designed. It's IMHO a horrible
mess and hard to work with. Most usefull dokumentation are just
listings of APIs, the only books that covered a little bit more
are out of print for decades. Hence very few people know X11
programming these days.

IMHO xlib and maybe even X11 as a system needs a huge
brush up to get into the 21st century.

> ALSA is horribly misdesigned and undocumented and thus has suffered
> multiple generations of incompatible interfaces and countless bugs.

So has most interface i know. Having more than one revision
of an interface is not a bad thing. It just shows that the
previous ones were not up to the task because not all
variables were known.

> > I fear this thread is in way degenerating into the microkernel vs.
> > monolithic kernel troll. It may be wiser to stop...
> 
> Note that if Linux had learned anything from Plan9, we wouldn't be
> having this discussion. Applications which want simple
> framebuffer-style graphics or simple audio access would just open the
> proper device files and perform IO on them, and could then work
> equally well on X or raw console, NAS/arts/esd or plain OSS, etc., all
> using the clean, simple, natural unix/plan9-style IO model rather than
> horrible bloated libraries.

Well, i had a short look at Plan9, it has great ideas, but it sucks
if you want fast videou output (unless they changed their aproach
drastically). But i have to agree with you, Linux isn't the epitome
of OS design. It doesn't has to be. It's good enough for 90% all
use cases. There are things that could have been done better, but
well....


				Attila Kinali
-- 
Praised are the Fountains of Shelieth, the silver harp of the waters,
But blest in my name forever this stream that stanched my thirst!
                         -- Deed of Morred



More information about the MPlayer-dev-eng mailing list