Skip to content

PATTERN Cited by 1 source

Classic DSP over ML for compute-constrained targets

Problem

An ML-based alternative to an established DSP (digital signal processing) technique exists and produces higher quality at the same bitrate / memory / operating point. But the ML alternative's compute cost exceeds the budget on your target-device population. Deploying the ML version serves only high-end devices; deploying nothing serves nobody well.

Pattern

Keep the classical DSP direction. Pay the engineering cost to push it further on parameter quantization, coding schemes, excitation generation, or architecture (e.g. split-band decomposition) to close the quality gap that made the ML alternative attractive — without blowing the compute budget that rules it out.

This is not "simpler is better." It's "the compute-constrained direction requires more engineering investment, and that investment is the right call when the install base demands it."

Canonical example — Meta MLow over Meta Encodec

Meta had its own ML codec — Encodec — available, with "amazingly crisp audio quality at very low bitrates". But:

  • >20% of Meta calls are on ARMv7 devices.
  • 10s of millions of daily WhatsApp calls are on 10+-year-old phones.
  • Encodec and peers require "the very high-end (expensive) mobile handsets" to run reliably.

Rather than ship Encodec and abandon the low-end population, Meta spent ~2.5 years (late 2021 → mid-2024) building MLow — a classical CELP-based codec with split-band architecture + range encoding that outperforms Opus 2× on POLQA MOS at 6 kbps while running 10% cheaper on CPU than Opus. The direction is classical-DSP; the delta over baseline CELP is where the investment went.

Meta's quote:

"These newer computationally expensive codecs [ML codecs] is actually limited to a small portion of users. A significant number of our users still use low-end devices… we clearly need a codec with very low-compute requirements that still delivers high-quality audio at these lowest bitrates."

(Source: sources/2024-06-13-meta-mlow-metas-low-bitrate-audio-codec)

Broader echoes on this wiki

The same shape shows up whenever compute constraints force classical over learned:

  • concepts/quantization / Instacart's decision to not ship FP8 quantization on their Llama-3-8B SRL student despite a 10% latency win — the quality regression moved them back to the non-quantized path.
  • Any on-device ML story where "ML-accelerated" loses to classical DSP under real battery + thermal + CPU budget constraints.

When it applies

  • The user / device population has a meaningful low-compute tail (>10% typically).
  • The ML alternative's compute cost is device-excluding, not just slower-but-feasible.
  • The classical direction has not yet been pushed to theoretical limits — there's headroom to refactor parameter quantization, architecture, coding schemes.
  • The engineering-team cost is justified by the user-population impact.

When it does not apply

  • The compute delta is modest and within budget on target hardware.
  • The ML technique is objectively more compute-efficient per unit quality than the DSP baseline (rare in production-on-phone audio today; increasingly common in text / vision on server GPUs).
  • The application tolerates a hard tier split (pro vs consumer) at the codec layer — RTC typically does not.

Seen in

Last updated · 319 distilled / 1,201 read