LC3 codec as a frame-level audiodsp module (research done; nothing decided)

[bdbarnett]

The feasibility research is in the workspace anchor at docs/lc3-feasibility.md (2026-09-24). liblc3 (Apache-2.0, no allocation, single-precision float, about 14 KB of state for a 48 kHz encoder plus decoder) fits every target we build. The recommendation is a small hand-written module here, beside audiomp3, rather than the lvgl-bindings generator. Build it without the LC3plus modes, and compile liblc3 into our own CPython extension rather than depending on lc3py.

The one decision to make now: the API should be frame-level. Encode takes PCM and returns one frame; decode takes a frame, or None for a lost one, and returns PCM. That keeps an LE Audio (ISO) transport possible later without a rewrite.

Nothing is decided and there's no GO. If it goes ahead, the first step is to measure CPU time per 10 ms frame on the S3 and the P4, because no microcontroller figure has been published. The radio gap (none of our boards has ISO channels, and Espressif LE Audio is H4/S31 preview only) is written up in the anchor's docs/ble.md and the feasibility doc.

[bdbarnett]

This one has no decision on it yet. It isn't parked and it has no GO, so it's the only open audiodsp issue without a next step.

Brad, do you want the first step run now (time one 10 ms LC3 frame, encode and decode, on the S3 and the P4), or should this be parked until something can carry it? None of our boards' radios can do LE Audio ISO today, so a codec would only have a use in files or over Wi-Fi.

I'd park it, with the trigger "a board with an LE Audio-capable radio is on the bench, or you want LC3 for a non-Bluetooth use". The feasibility write-up keeps until then, and the frame-level API point holds whenever it starts.

[bdbarnett]

Brad's decision (2026-09-26): parked until a PyDevices board's radio can carry LE Audio. Until then a codec has nowhere to go. The research here stands.