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

[Rich Felker]

On Fri, May 04, 2007 at 01:24:28PM +0400, Vladimir Mosgalin wrote:
> > > Look. If design (the one that you offer) doesn't provide required
> > > features, than it's wrong. If some other design provides these features,
> > > then it's better design. Easy as that.
> > The difference is our definitions of "required".
> 
> Sure. However, card at least should work. A have a very nice sound card
> which can't be used through oss emulation in alsa, it seems. Some other
> cases can be mandatory, too, like when your card is connected to DAC by
> digital connection and you want to listen to surround, you'll HAVE to
> recode everything to ac3. Sometimes there are no other solutions (though
> you probably think that surround sound is always unnecessary,

Of course I know it's always unnecessary.

> well why
> don't you go back to mono then..).

Because I have 2 ears, not 1 and not 6.

> Some programs on my system use about 80 libs and start fast, what am I

Already cached.

> doing wrong? I fail to see how 100 open/read calls will make a 5 second
> delay.

At least 100 seek operations on the media. Seek times in reality are
nowhere near as low as disk manufacturers advertise.

> > DVD-sized video should not need any postprocessing unless it was
> > encoded by idiots...
> 
> everybody except for you is idiot, remember..

No, all the DVD-sized videos I have don't need postprocessing because
the people who encoded them are competent.

> > I couldn't care less about new computers because buying a new computer
> > is always a mistake. It's socially and environmentally irresponsible
> > and a huge waste of money.
> 
> It's your choice, but when you are developing software, you should care
> about them, if you expect your software to run nicely on them.

If it runs nicely on old computers it will also run nicely (even
better) on new computers. The converse does not hold.

> > > really sucks. You should've just used library directly. And you can't
> > > miss that userspace audio processing lib because your audio card may
> > > support only some very obscure format which your app doesn't know about
> > > or because mixing is done in that lib.
> > 
> > Using the library directly from your application locks you into a
> > particular (BAD!!!!) API. Using it indirectly and only speaking a
> 
> ioctl api isn't any better. Absolutely no difference.

Yes it is. It's a small number of commands with trivial messaging
structures or single integer arguments instead of complex data
structures and a huge set of symbols.

> > clean API direct to the kernel keeps you free to replace the bad
> > implementation with a good one without breaking apps.
> 
> If you just don't like api, what about some kind of preprocessor which
> converts ioctl calls that you like so much to real alsa calls?

Fundamentally not possible. The other direction is of course possible.
That's why the library crap should be built on the clean device API
and not vice versa.

> > > Which one? Send your guesses! By private mail, if you wish. Let's play a
> > > game, "making mplayer's oss output work for usb soundcard".
> > It's not a game, it's called fixing bugs.
> 
> There are no bugs. oss emulation is hardly working at all, in all cases
> except described above ("soundcard with hardware mixing, supporting any
> sound rate and most popular sound formats with stereo-only output"). I
> don't see any bugs in the fact that it doesn't work. And it's not
> mplayer bug for sure.

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.

> > You should study curses. How is it any easier to use curses "moveto"
> > function than writing the escape sequence to the file descriptor
> 
> I used curses and I know how escape sequences work, but you are choosing
> a wrong example - what about windows/panels, for example? Such code
> belongs to library, not to program.

Curses windows/panels are disgusting bloat. It's like saving an image
of your window contents in an XPixmap and blitting it on window-expose
events instead of processing the expose event and redrawing!

Your program knows how to draw the window contents because it drew
them the first time. Thus, it can draw them again when it needs to!
There's no excuse for keeping an image of what you draw to the window!
This applies both for gui and for terminals.

> > would have been any problem. We STILL have that issue with bidi text
> > -- curses doesn't support it because almost no terminal supports it,
> > and terminals don't support it because curses doesn't support it. The
> 
> So it doesn't "just work", and requires some advanced code to behave
> properly? But right now it only needs to be implemented in terminal and
> curses, right?

Nope, it needs to be implemented in the terminal, curses, AND the
application. Fully-correct bidi support is not possible without
support from the application. Partly working support is possible with
implicit bidi only, but then the screen will look wrong if the
application draws menus/dialogboxes/popups/etc. over top of a region
with bidi text.

If curses weren't present, only the app and the terminal would need to
have bidi support.

> Well, maybe some small fixes in application. However,
> you suggest that each and every program should implement the whole bidi
> supporting code in itself!

It's necessary anyway. They're free to use a library (like freebidi)
for it, but it's impossible to have it just work.

> THAT way it would never be implemented except
> maybe in 2-3 most popular applications. Hey, if you say that application
> shouldn't use curses and want to implement it in your application
> yourself, what stops you? Console vim supports bidi for a long time,
> even though curses "don't support it".

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

If you're interested, read the ECMA-48 standard and what it has to say
about bidi.

Rich