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

[Vladimir Mosgalin]

Hi Rich Felker!

 On 2007.05.04 at 10:48:53 -0400, Rich Felker wrote next:

> > What about browser,
> 
> None exists, they're all utter crap. For some tasks elinks is best
> available, for others iceweasel is best available, but both (and all
> others) royally suck.

I'm pretty fine with my firefox..

> > video player, audio player (I finally moved from
> > mplayer to REAL gui audio player with nice library browser - I can say
> > that it rocks..),
> 
> Thanks for showing your irrelevance again. If you like this gui crap
> so much why not go troll their lists and get off ours??

It doesn't use alsa, it uses gstreamer. Actually, that was one of the
reasons why I choose it - right now gstreamer is about the only way to
get very high quality audio processing chain in linux. Yeah I know you
probably don't believe me, but it's the sad truth..

No, this "very high quality processing chain" wasn't the feature of the
player originally, it's just that it was pretty easy to change this
part, considering gstreamer's architecture.

As about gui, when you have a big audio library, there are many uses for
gui.

> FYI, MPlayer's sad gui is the only one I've tried which even
> _attempts_ to display UTF-8 filenames correctly in the file/playlist
> selector. So much for "advanced" gui players...

I don't care about gui in video player. Also, I haven't seen a program
which has problems with utf8 for a very long time.

> Uhg, disgusting. Only viable IM client is bitlbee.

gajim looks nicer.

> > and GUI editor?
> What, n[ewb]edit? Sorry there are basically 2 editors, emacs and vi,
> depending on your style/preference. Neither needs gui and both are
> better without.

No, gvim. It is so much better and more capable than regular console
vim (for a quick example, try editing .xpm file in vim versus gvim).
Well, as long as you rebuild it with athena or motif and throw away
menus/toolbars/dialogs which take space, unfortunately vim is built with
gtk or gnome gui by default in most distros, which makes it slower and
less capable (because it ignores X resources this way).

> This statement is blatently false. Audio processing is trivial. You
> deliver samples to a device, in a format supported by the device, in
> sequence and measure the current playback position in the buffer.
> Nothing else is needed.

And each and every application has to support each and every fancy
soundcard which has some obscure sample format? In your dreams. This
will never work. No one would use oss then, everybody would use SDL or
something else which does proper conversion disregarding the app. And
it's return of alsalib.

> > That's all. Simple as that. I'm defending alsa library interface simply
> > because it fits into my ideas perfectly, and right now it's the ONLY way
> > to get working audio on linux for most people.
> 
> This is false. OSS API works for everybody just fine. Your problem
> report is NOT a bug in OSS API but a bug in MPlayer, which you refuse
> to report.

I have 4 (four) audio devices on my computer. Well, actually 5.
1) Audigy regular interface (can also be used for ac3/dts passthrough)
2) Audigy second, HD audio interface
3) USB interface, digital out
4) USB interface, analog out
5) USB interface, digital out, works only for ac3/dts passthrough.

Of these, only first one supports hardware mixing, sample rate
conversion and random format. 3) and 4) support almost any sample rate,
but not any sample format. Only the first one works over oss api for
sure (maybe 5) does too, not sure).

It's not really mplayer's bug, take even most basic oss applications
like mpg321, soxplay or anything else - nothing works with oss
interface. In fact, I don't even see oss interface for usb card, I have
/dev/dsp and /dev/dsp1 devices for 1) and 2). I'll finaly remove audigy
card on the next boot and will see if it appears at all.

However, no oss application manages to work even with 2). NOT A SINGLE
ONE. What should be fixed then, mplayer? Alsa? OSS API?

-- 

Vladimir