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

[Rich Felker]

On Sat, May 05, 2007 at 02:43:20AM +0400, Vladimir Mosgalin wrote:
> > 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.

Disagree strongly, but OT.

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

No, it's a bad thing for quality. No degree of digital signal
processing can give the correct result you'd get from correctly timing
the output clock to the samplerate of your recording; any resampling
involves tradeoffs between artifacts, destruction of high frequency
content, etc.

> Because it can be done in software
> and therefore should be done in software,

And just a minute ago you were saying doing things in software (3d
graphics) was a bad idea.. Now you say resampling should be done in
software just because it can? Make up your mind!

> > In the fastest mode, it's slower than libavcodec's resampler.
> 
> No one cares. In normal mode, it takes marginal amounts of cpu.

And sounds like utter shit.

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

Do listening tests. It was done by someone I know and found to be very
bad. Also, max quality mode in ALSA is so slow it's unusable, so it's
irrelevant.

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

It was discussed recently on the lists. My friend (same one mentioned
above) wrote and submitted a patch to allow ALSA to use lavc
resampler. I believe it was accepted but not enabled by default, and
in fact it's problematic because linking in lavc will cause symbol
clashes in any program which uses its own version of lavc. This is yet
another reason why implementing ALSA as a library is idiotic. If it
were a separate process mediated correctly by the kernel, it could use
whatever libraries it wants without clashing with application's
namespace.

Rich