[vorbis-dev] New LSP code committed

[Segher Boessenkool]

> 
> > How are you going to do the fromdB() without using exp()? Couldn't figure
> > out how to factor out the fromdB() after the lsp_to_curve(). Are you
> > doing the fromdB by table lookup or something? I guess that is worse...
> 
> I was going to make table lookup an option to replace everything past the p/q
> multiplicitive sum loop and before the residue dot product, yes (probably

dot product? I assume you mean cartesian product (c_i = a_i * b_i ; 
dot product: c = sum_i a_i * b_i).

> software selectable as a 'fast' mode.  For fixed point projects, the lookup
> would be essential). As the usable range is only about 140dB, a fairly fine
> grained lookup would not be exhorbitant, and a granularity of 1dB is still
> acceptible for most purposes. We could even interpolate the lookup for extra

If the 1dB is at most half of the error introduced by quantization, there's
no need to bother with interpolation :-)

> precision, as I'll be doing to replace cos() in lsp_to_curve (the cos() call

The cos itself isn't that heavy (on pc processors; embedded is different,
of course).

Oh, you can calculate the cos'es by CORDIC; no need for a look up table
or actual cos() calls. Expect a patch soon :-)

> there uses exceptionally fine angles, but the actual precision of the
> instantaneous slope of the cos() function isn't really that important.  A
> linearly interpolated 128 entry cos() lookup adds less than .01 dB of
> inaccuracy in my empirical testing, but that interpolation is essential!)

Do you have pointers to papers about lsp which discuss precision or
stability? Getting scared of the thing...

> 
> > vorbis decoding uses too much memory at the moment (cache wars). Maybe
> > some pipelining will help.
> 
> Yes, it's true.  Alot of that is poorly organized lookups. Precomputation 
> isn't always a win... :-(
> 

'fraid not, no.

Btw, I was a bit pessimistic about the fromdB lookup; I was assuming a
todB lookup. Yes, reading is difficult. As well as thinking.

A fromdB lookup will cost 1-2kB mem; a fromdB (with the same precision)
about 32-64kB. Or use some funky cutoffs, then it's 2-8kB (assuming most
numbers will be in range for the table; else misprediction kills you again).

But a fromdB lookup will be reasonable. Oh, table can be smaller: make
2 lookup tables:

fromdB(aN+b) = tabA[a] * tabB[b];

You can split in 3, 4, whatever; but 2 will be small enough.

Dagdag,

Segher

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/