A board role for encoded audio (VS1053 Featherwing)

[bdbarnett]

The audio format contract renames the raw roles to pcm_out / pcm_in precisely so that a peripheral which is not PCM gets its own name instead of lying through a vague one. Brad owns the peripheral that proves it: an Adafruit VS1053 Featherwing.

The VS1053 is neither PCM in nor PCM out, in either direction:

• Out — you push encoded MP3 / Ogg Vorbis / WAV / MIDI bytes at it and it decodes to its own DAC. Not a PCMOutput.
• In — it encodes from the mic/line input to Ogg Vorbis. Not a PCMInput.

So it needs a role of its own. Shape is undesigned; the open questions are:

• Role names. encoded_out / encoded_in? codec_out / codec_in? The word "codec" is already taken in this codebase for the chip drivers under drivers/codec/ (ES8311, ES7210, ES8388, AW88298), which argues against it.
• What the capability descriptor says. AudioCapability.kind is "pcm" or "tone" today; encoded needs a third value plus a container/codec list (mp3, ogg, wav, midi).
• Whether the MIDI synth half is an audio role at all, or belongs somewhere else entirely.
• Whether AudioFormat is even the right descriptor for a stream whose rate is carried inside the bitstream.

Not blocking the format contract — it is filed so the naming decision that makes room for it is recorded with the hardware that justifies it. Do not design this until the contract has landed on the three PCM boards.

Context: docs/audio-format-contract.md

[bdbarnett]

Parked (Brad, 2026-09-23). It reopens when Brad wants to use the VS1053. The format contract it was waiting on has landed (pydevices v0.4.0). The naming note above stands: the role is encoded_out/encoded_in, not codec_*, because 'codec' already names the chip drivers under drivers/codec/.