Skip to content

EXPERIMENTAL build 245af06 — DSP perf + VibeServer bookmark/squelch fixes

Pre-release
Pre-release

Choose a tag to compare

@Stuey3D Stuey3D released this 14 Jul 20:11

⚠️ EXPERIMENTAL — not a release. Built from experimental, for testing only. Needs an ear test.

DSP performance (affects Local Hardware and VibeServer)

Two real inefficiencies found by benchmarking the engine on a Raspberry Pi (tools/pi-bench):

  • WFM was decimating to 3× its bandwidth. The comment in pipeline.cpp has claimed 1.5x since the day it was written; the code said bwHz*3.0 and git log -L proves it was never anything else — the fix was described and never landed. Worse, at 1.024 MSPS the decimator decimated by one — the entire MPX chain (stereo PLL, 16 RDS decoders, de-emphasis, 15 kHz filters) ran at the full input rate. That is why lowering the sample rate made WFM more expensive instead of less.
    • WFM @ 2.4 MSPS: 8.5% → 3.6% of a core
    • WFM @ 1.024 MSPS: 18.7% → 2.6%
  • The channel filter was decimating 50:1 in one step, forcing a ~750-tap filter to run at the full 2.4 MSPS (~36M complex MACs/sec). Now cascaded (50 → 5×5×2): the early stages only stop aliases folding into the channel (~9–17 taps each), and the narrow filter runs last, at the lowest rate, where taps are cheap. Same filter shape.
    • AM 1.8% → 1.0%, NFM 2.1% → 1.0% (on NEON; the win on a scalar/32-bit ARM box is larger)

Worth watching: WFM stereo on low-end phones (Moto G35, Xcover 4S). The original comment blamed this exact bug for "choppy audio on budget phones".

VibeServer fixes

  • Learned RDS bookmarks were never saved. bmLearn() was the one bookmark mutator that never called bmSaveLocked() — so a station you genuinely learned lived in memory only and died with the process.
  • …and would never have shown anyway. The web client fetched /bookmarks exactly once, at page load. RDS learning needs ~20s of held PS to commit, so the station you're sitting on is always learned after the page loaded. It now polls every 30s, like the native app always has.
  • Squelch no longer reports itself as a fault. Squelch is applied server-side, so a closed squelch and a muted tab looked identical to the audio engine — it threw a pulsing red "NO SOUND — IS THE TAB MUTED?" that also hid the S-meter, the one thing you want to watch while waiting for a signal. Now a steady amber "NO AUDIO — SQUELCH ENABLED", meter left visible.

Test focus

  1. FM broadcast, stereo + RDS — does it still sound right, and does stereo lock?
  2. SSB/AM on HF — any change in selectivity or adjacent-channel bleed?
  3. Sit on an RDS station ~30s → does it appear in bookmarks, and survive an app restart?
  4. Squelch on with no signal → amber, steady, meter visible.