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

[Vladimir Mosgalin]

Hi Rich Felker!

 On 2007.05.04 at 17:14:16 -0400, Rich Felker wrote next:

> > Anyway, there is no point in discussing this. Even 720p and 1080p
> > material sometimes needs filtering. No pp filter is needed, but
> 
> Linear sharpening filters are fundamentally mathematically incorrect

Who cares, if it looks better?

> and also visually incorrect. All they do is make nasty halos around

Sometimes. Sometimes positive effect is more significant.

Anyway, it's up to people preference. I prefer sharpened video over the
oversmoothed one. Besides, spp/pp7 algorithm smoothes video quite a
lot. I have also smoothing video output (gl with lscale option), so a
bit of sharpening (small, like unsharp=l3x3:0.8) makes almost any video
better.

> But this is not how the application was intended to be run. And in
> fact from my experience it looks extremely bad. If you're going to use
> high resolution, you need millions of polys. Just taking a game made

Millions, you say..

> to run at 320x200 with soft 3d and running it at 1600x1200 with 3d
> accel just shifts the "offensively" bad resolution from an issue of

I know only one example of this, quake in 320x200 vs. glquake ;) Second
one looks much better.

> pixel resolution to an issue of polygon resolution. That is, instead
> of seeing pixels glaring at you, you see polygons glaring at you.

Textures and polygon edges will be smoothed at least..

> In any case, the point is that the program runs just fine. And
> _predictably_. It runs exactly as it was intended to. Maybe you wish
> it would dynamically evolve to the capabilities of your new system you
> wasted lots of money on, but that's irrelevant.

Well this is completely OT. The original problem is that it doesn't
happen with oss interface in alsa, because modern hardware in a way is
even more limited than old one, despite being better. The lack of
hardware mixing and random sample rate/sample format support in hardware
is a very good thing, quality-wise. Because it can be done in software
and therefore should be done in software, with desired quality level, as
opposed to unknown hardware implementation. But it creates problem for
old software.

> In the fastest mode, it's slower than libavcodec's resampler.

No one cares. In normal mode, it takes marginal amounts of cpu.

> In the best quality mode, it's lower quality than libavcodec's
> resampler.

You cannot prove that. I believe what my ears tell me: its quality is
good. I don't want to discuss libavcodec now, but if quality is already
_good enough_, if it is _very good_, why bother saying that "it's lower
than something", if you ears won't notice that anyway?

> configurable between two extremes of sucking: very bad quality, or
> very bad performance.

It has 5 different quality levels.
Try "samplerate" one. "samplerate_order" and "samplerate_linear" suck
quality-wise, but "samplerate" is good. I honestly can't imagine why
anybody would say that its quality sucks.

As about performance, well don't use _medium and _best modes! Honestly.
Can you give a single example of bad quality in normal mode? Show me
any sample and tell what rate should I resample it to, and try to
describe what kind of artifact do you hear with default "samplerate"
resampling comparing to lavc resampler. Until you give such example,
stop spreading BS. "samplerate" is as perfect as anybody might desire,
at least for most common 44.1->48k and 44.1/48->96k tasks.

-- 

Vladimir