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

[Vladimir Mosgalin]

Hi Rich Felker!

 On 2007.05.03 at 18:51:35 -0400, Rich Felker wrote next:

> > No. In this case, yours interests are special; regular people around
> > want to easily utilize surround capabilities, plug in webcams/usb
> 
> Surround sound is already a special-interest for audiophile idiots who
> can't count the number of ears they have and who flunked linear
> algebra...

No audiophile or person who wants to enjoy quality music will listen
stereo music in surround; and surround music is still very rare, both
SACD and DVD-A are basically failed. A lot of audiophiles listened only
stereo part of these discs anyway..

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.

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

> A system with 10-levels-deep lib dependency trees, hundreds of megs of

You don't offer anything better.

> libs, 5-second load times due to symbol resolving, etc. is NOT VIABLE

Open wonderful world of DT_GNU_HASH and prelink to yourself.

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

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've only encountered one application I wanted to use which had gnome
> dependencies, even on Debian which is notorious for making things
> depend on optional gnome functionality. Gnome is mostly a collection
> of toy "accessories" applets and ugly "desktop integration" glue, not
> useful applications.

Actually, the reason why I like gnome most is because of some really
wonderfull applets. Much better than wmaker applets. Isn't that enough
reason to use gnome or other desktop system? Desktop consistency and
some useful applets.

> > The descriptors aren't suited for audio at all and should be deprecated.
> > No point in discussing them!
> 
> You provided no reasoning here; thus I'm going to ignore your stupid
> claim.

Hey, I just tried to answer in your style. As of arguments, they were in
the rest of post.

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

> > People won't use commercial oss drivers. Oss/free in kernel is dying,
> > almost dead.  Alsa-oss emulation in kernel doesn't provide necessary
> > features and hardly even works (for example, it doesn't work at all for
> > my usb soundcard - mplayer only prints 
> > "[AO OSS] Can't set audio device /dev/dsp1 to s16le output, trying s16le...\n"
> 
> 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".

> Keep calling it fuse-like; this is historical revisionism and probably
> not quite correct since I don't think fuse can implement devices, only
> ordinary-file-like semantics. The correct way of saying it is

There is fusd, library which oss2jack uses.
http://fort.xdas.com/~kor/oss2jack/

> You can and many many people did, before the days of people using

Why? Just to lose a lot of time, make unreliable programs and so on?

> wasteful 3ghz crap that's 100x faster and more power-hungry than
> anyone needs. (Yes old machines were even more power-hungry due to
> primitive tech, but if technology had evolved in the responsible way
> we should be using 30mhz machines with 0.5watt power usage instead of

Why, just for the sake of it? You understand that they wouldn't have
costed less than modern cpus? Because of marketing laws.

> 3ghz machines with 300watt power usage.)

You can get 2ghz A64 cpu with 25 W (IIRC) top power usage and very good
energy saving modes, isn't that enough? There is no point in 0.5 W.

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. And as popularity of powerful smartphones and UMPCs
rises, even more energy efficient cpus will be produced.

> For drawing something complex, you're totally free to use or implement
> libraries built upon the lowest-level primitives. That doesn't mean
> that everyone should be confined to the same _BAD_ library. But this

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.

-- 

Vladimir