[MPlayer-dev-eng] [PATCH] More accurate af_volume

[Zoltan Hidvegi]

D Richard Felker III wrote:
> > This is audio, suppose the worst case, 6 channel 48000Hz, 576000 ifs
> > which 99.9% of the time evaluate false.  On a 1GHz CPU this adds maybe
> > 1ms overhead per audio second.  But I agree, a separate filter may be
> > better.
> 
> Conditionals are incredibly slow on most cpus, and not acceptable at
> all for useless "toy" features. Something slow and irrelevant to the
> volume filter, and this "feature" definitely is both, belongs in a
> separate filter.

So that's what I did, in my last patch I no longer have the max code.

> > > And if that rounding really is worth one add more...
> > 
> > An add is almost costless, it's a pure register operation.  Let's say
> 
> It's also 6 extra bytes in an inner loop, which has cache
> implications.
> 
> > this: if you can show measurable performance degradation coming from
> > this add, then we can remove it.
> 
> No, you misunderstand how MPlayer development works. It's the other
> way around. If you want to introduce a change that has theoretical
> detrimental impact on performance, then YOU must show that there is no
> performance degredation in reality, or withdraw the patch. We will not
> commit stuff which may slow MPlayer down without proof that it does
> not do so.

So you are saying speed wins over accuracy?  We are talking about one
add instruction per sample, in the typical case (stereo 48kHz) that's
96000 adds per seconds.  Even on very slow CPUs that is unnoticable.
Perhaps it has no audible effect, so maybe I can remove it, but I
still feel bad to introduce inaccuracy for an unmeasurable speed gain.

Zoli