[vorbis-dev] New LSP code committed

[Monty]

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

I'm sorry, you're correct.

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

Yes, an the cos might even be worth the FPU hit given the savings in cache.  
But I'll leave that up to you to answer ;-)
 
> Oh, you can calculate the cos'es by CORDIC; no need for a look up table
> or actual cos() calls. Expect a patch soon :-)

The needed lookup table is small, really.  256 bytes or so if done in 2-byte 
fixed point.  Of course, cos() may still be faster after interpolation, but 
the embedded people will love us.
 
> > 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...

No, it's behavior is actually very simple; easy to understand and easy to 
predict.  There are no stability issues and easily dealt with precision issues.
For a while I was treating it as a not-understood black box and it was 
worrying me too, but after spending a few weeks getting a real feel for it, 
it's *much* easier to deal with than LPC.  Levinson-Durbin is a good all-pole 
filter generation technique, else I'd eliminate LPC from Vorbis entirely and 
generate LSP directly.

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

I'll assume you typoed above and I know what you meant.  We'll be able to 
bound our table with just a little effort (our upper bound is a normalized 0dB 
even if we're using an offset scale, and lower bound is what you feel like 
giving the ear.  The format has no bottom floor, but I've been assuming 140dB 
working for the software codec.

> But a fromdB lookup will be reasonable. Oh, table can be smaller: make
> 2 lookup tables:
> 
> fromdB(aN+b) = tabA[a] * tabB[b];

Not as useful, unfortunately (tell me if I've missed it).  The only point where
we need fromdB is the ugly foo=amp/sqrt(p*p*(1.+w)+q*q*(1.-w)) computation in
lsp_to_curve (and then outside the function, those values are immediately taken
to linear amplitude with fromdB and an offset).  

Monty

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