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

[Rich Felker]

On Fri, May 04, 2007 at 03:36:07AM +0400, Vladimir Mosgalin wrote:
> 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.

> > > soundcard, drivers for which embeddes all these features. Awful design,
> > > a lot of problems, but at least it mostly works. In linux with alsa this
> > > all can be accomplished with much better design, though it's true that
> > Worse design than windows....
> 
> 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".

> > A system with 10-levels-deep lib dependency trees, hundreds of megs of
> 
> You don't offer anything better.

Yes I do, OSS API.

> > libs, 5-second load times due to symbol resolving, etc. is NOT VIABLE
> 
> Open wonderful world of DT_GNU_HASH and prelink to yourself.

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.

> > FOR USERS. Maybe for you stupid "buy a new computer every week"
> > windows kids with 100x-overspec toys, but that's not what the majority
> > of the world has, only a vocal minority of "enthusiasts". Like I said,
> > special interests.
> 
> Well, the one and only application where powerful cpu is useful for me
> is mplayer ;) Believe me, when you are able to use pp7+hqdn3d+unsharp on
> dvd-sized video and pp+hqdn3d+unsharp on 720p, it looks really nice.

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

> But I can't correlate your words; do you prefer slow old hardware and
> 5-second load time or overspec hardware and fast loading times? I don't
> think there is anything wrong with desiring a fast cpu, since nowadays
> more or less fast cpus are cheap as hell. And well, sometimes time comes
> to upgrade your computer. For example, one of my applications required
> about 4gb of memory during development (now it requires slightly more
> than 1gb, even though absolutely no one minded 4gb requirement); I
> couldn't have installed such amount of memory without upgrading to newer
> system.
> 
> As about regular users, I think most users coming to linux are people
> that are buying a new computer. Maybe their second system, maybe a
> notebook. Probably you heard about DELL going to sell computers with
> linux preinstalled. Have you seen the lowest specs of these computers?

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.

> > > Just like you can't work with 3d
> > > acceleration using descriptors (no, open("/dev/dri/card0") doesn't
> > > count), you shouldn't work with audio using them.
> > And why not??
> 
> Because nothing good will come out of this. Like I said, there are some
> requires features - even if you forget about surround, there are
> hardware mixing, compatible audio formats, sample rates.. This stuff
> doesn't belong to application and shouldn't be done in kernel, and
> 
> (descriptor)->kernel call->fusd or something->userspace audio processing
> lib->kernel->audio card
> 
> 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
clean API direct to the kernel keeps you free to replace the bad
implementation with a good one without breaking apps.

> > Then specify the right format settings for your device in your MPlayer
> 
> 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.

> You can get 2ghz A64 cpu with 25 W (IIRC) top power usage and very good
> energy saving modes, isn't that enough?

No. 25W = horrible battery life.

> There is no point in 0.5 W.

Anywhere mobile or with unreliable grid power.... Or just someone who
doesn't want to be constantly contributing 25W (actually much more!)
of energy usage to the pollution of the planet...
 
> In fact, modern CPUs are quite energy efficient. Technology is
> advancing, too. They are becoming smaller and colder. Energy saving
> modes are becoming more efficient. Multicore processors get the ability
> to turn of some cores and even to rebalance speed, i.e. turn off one
> core and overclock another while generating the same heat when user runs
> some single-threaded cpu-hungry app. You don't have enough faith in
> modern technology.

Because it doesn't deserve it. These are all stupid approaches and
nowhere near 1% of the efficiency they could achieve if they were
designed right.

> So you think that since curses is a really nasty library, each program
> which used curses should parse terminfo itself and use low-level
> sequences for drawing? Good luck with that approach.

You should study curses. How is it any easier to use curses "moveto"
function than writing the escape sequence to the file descriptor
yourself? curses just wastes tons of ram keeping its own copy of the
display contents in core, and it also stifles innovation, because new
terminal features cannot be used due to curses not supporting them.
For instance, it took FOREVER to get proper UTF-8 support in tons of
console apps, because ncurses botched UTF-8 and failed to be
8bit-clean. If the apps had been using terminfo directly there never
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
same thing happens with OpenGL and new graphics features, but they get
supported through nonstandard vendor extensions instead...

Rich