[MPlayer-cvslog] CVS: main/libaf af_ladspa.c, NONE, 1.1 .cvsignore, 1.1, 1.2 Makefile, 1.18, 1.19 af.c, 1.34, 1.35

[D Richard Felker III]

On Fri, Dec 24, 2004 at 11:47:36PM +0100, Reimar Döffinger wrote:
> Hi,
> > > [...]
> > > > > I just don't think that is what you want. It will give you values in
> > > > > between -1 and (1 - 1/32768), thus scaling positive values a bit smaller
> > > > > than negative ones. This will produce inaccuracies with almost any filter
> > > > > that does anything useful.. I really think you should use unsigned as
> > > > > input format and multiply (faster than division) by (2.0f / 65535.0f) and
> > > > > then subtract 1.0f. And for converting back add 1.0f and multiply by
> > > > > (65535.0f / 2.0f). You can of course write the numbers out, if you don't
> > > > > want to rely on the compiler optimizing it...
> > > > 
> > > > I agree. I don't know what I was thinking there, although it is better than 
> > > > what was previously in the proposed patch. The inaccuracy is only 0.003%, 
> > > > so I don't think it'll be a big problem in -pre6. Nevertheless, it's wrong 
> > > > so I'll fix this.
> > > 
> > > Actually I'm not too sure anymore if it's wrong - at least I think you
> > > will always have some inaccuracy in that conversion...
> > > Actually... Why don't you just request float sample format 
> > > (AF_FORMAT_F | AF_FORMAT_NE | AF_FORMAT_SI) from mplayer?? This will be a big 
> > 
> > FLOAT SAMPLE FORMAT DOES NOT WORK!!!!!!!!!
> > 
> > It will load 20 different random conversion filters between formats
> > that don't even exist, like "8bit unsigned float", use 50% cpu, and
> > output white noise in the end!
> 
> Are you sure? If so don't you think it would be better to fix it instead
> of duplicating code?

Yes. It seems to work for some people, but not others. I expect
uninitialized variables or other broken code that's causing random
behavior that works with some cpus or compiler versions and not
others..

Anyway fixing it would be good, but removing float nonsense would be
much better.

> > All filters should (IMNSHO _MUST_) operate internally on integer
> > samples, simply because float is unusably slow on many platforms (even
> > if float format is fixed).
> 
> Tell use how this should be possible in this case and I'm sure it will
> be done. I think we all know the problems with floating point, as well
> as your opinion on it...

Just modify the code to use int samples...?

Rich