David & Co.,
While characterizing Codec2's LPC stage for a from-scratch Rust port
(aiming at fixed-point for FPU-less embedded targets), the AI and I
found something that seems worth flagging upstream rather than just
working around locally.
Levinson-Durbin's k = -(r[i]+sum)/e step divides by the running
prediction-error energy e, which is monotonically non-increasing and
can get very small on strongly-predicted (clean, resonant) frames.
Against 2532 real captured speech frames, we measured e bottoming out
at ~2.76e-4 relative to r[0] on the worst frame, giving a ~3581x
amplification of whatever rounding error already exists upstream. This
shows up even in plain float32 vs. float64 with zero fixed-point
involved — 0.04% of frames diverge outright between the two, another
0.4% show a smaller real perturbation. It's a property of the
recursion's own conditioning at that frame, not an implementation bug:
we confirmed this precisely on one specific case by building a more
mathematically exact normalization step, which still diverged from the
current f32 behavior, because even f32's ordinary ~1.7e-8 relative
rounding error is load-bearing for which answer you get on that frame.
The standard fix (white noise correction / autocorrelation
regularization, Rabiner & Schafer 1978) resolves it well: multiplying
R[0] alone by (1 + 1e-3) before Levinson-Durbin — leaving R[1..10]
untouched — drops the worst-case amplification from ~3581x to ~269x
across the same corpus, a >13x improvement, for an energy correction
(~30dB below signal) far under the audible threshold. It also
independently resolved a second, separate fragility we'd found in a
fixed-point normalization step, which is a decent sign it's addressing
a real root cause rather than patching one symptom.
I understand this is legacy work and you have moved on. However I felt
that getting M17 on really cheap HTs and ESP-32 Extensa-class
processors that would not support machine learning might still be
worthwhile. I am wary of making AI-mediated bug reports, feel free to
dismiss this one if appropriate.
Thanks
Bruce
---
--
Bruce Perens K6BP
_______________________________________________
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
