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

[Vladimir Mosgalin]

Hi Rich Felker!

 On 2007.05.03 at 21:32:13 -0400, Rich Felker wrote next:

> > However, now almost everyone buys cheapes "5.1" systems (you can buy one
> > for less than $50) and wants to listen mp3 in surround. Yeah it sounds
> > like shit. Nobody cares.
> This is plain stupid.

Yes. And a lot of people still like it. Not because they are stupid
(according to you they might be, I presume, but..), but because they
care abound "surroundness" of sound much more than of its quality.
Industry uses this. And computer sound systems just have to let them do
what they want, saying "what they want is wrong and it shouldn't be
done" IS stupid, it's no the way the world works.

> > 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, well why
don't you go back to mono then..).

> Yes I do, OSS API.

It's unworkable. When you want anything complex or just have some
strange sound card/speaker setup (most people do nowadays, comparing to
"soundcard with hardware mixing, supporting any sound rate and most
popular sound formats with stereo-only output" solution, the only one
that fits nicely into current state of oss api), you can't use oss.
Maybe oss could be designed to support them; the thing is, it isn't, and
it's not going to change.

> Piling more complexity on top of mistaken complexity is not a
> solution. It's pure stupidity. Besides all the libraries still need to
> be _opened_. Even if only one symbol is used from each lib, if 100
> libs need to be opened before control passes to the program, you'll
> have 5+ second delays.

Some programs on my system use about 80 libs and start fast, what am I
doing wrong? I fail to see how 100 open/read calls will make a 5 second
delay.

> DVD-sized video should not need any postprocessing unless it was
> encoded by idiots...

everybody except for you is idiot, remember..

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

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

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

> > 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. Maybe mplayer can fixed to work with that, however
old dumb ("dumb" as "simple") programs which just open "/dev/dsp", do a
few ioctl calls and then just try to write there can't be fixed. Modern
soundcards just don't work this way, and all this software can't be
fixed to support them. On the other hand, even simplest program which
uses alsa will work.

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

> 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?  Well, maybe some small fixes in application. However,
you suggest that each and every program should implement the whole bidi
supporting code in itself! 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".

-- 

Vladimir