Speaking of this, I got Codec2/legacy FreeDV to run on an ESP32-S3, no mods or use of fixed point required. Granted, this wasn't the 3200 bit mode, and I can see the value of trying for a fixed-point implementation for the other chips in Espressif's lineup.
-Mooneer K6AQ On Fri, Sep 4, 2026 at 2:12 PM Bruce Perens via Freetel-codec2 < [email protected]> wrote: > 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 >
_______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
