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

[D Richard Felker III]

On Sun, Feb 20, 2005 at 01:55:16PM -0600, Zoltan Hidvegi wrote:
> > I would really hate to bloat a performance-critical so much.
> > First, getting the maximum really should be a separate filter IMHO, this
> > has no place in the volume filter (and believe me, those two ifs can
> > easily mean a 50% performance hit). The fact that it was already done
> > for the float case does not change this...
> 
> 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.

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

> > Also I think the register before int vol should stay.
> 
> OK, I can add it back, but do you know of any compiler where this
> really makes a difference?  If you really worry about speed, I can
> write all this in MMX, but I do not think it worths the trouble, and
> it will be harder to maintain.  The float softclip uses sin(x) for
> every sample, and even that is hardly noticeable on my machine.

That's because your machine is over 20x faster than MPlayer needs.

Rich