diff --git a/AGENTS.md b/AGENTS.md index 4f88661..215bc90 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -510,6 +510,43 @@ plausible way to stall a scan, and the S-meter work made the receiver always bus Page 4 is *not* the meter row, incidentally — it stayed byte-identical across all six samples while the frequency changed. +### Audio: there is nothing to model, and that is the finding + +"Add a speaker and a microphone, then grant the browser audio permission" is the +obvious request, and it cannot be done — not for lack of effort but because neither +device is on the MCU. Receive audio is demodulated inside the BK4819 and leaves as +analogue on its AF pin; transmit audio goes from the microphone into the chip's own ADC. +The firmware touches only: + + PA8 amplifier enable (GPIO_EnableAudioPath, driver/gpio.h:34) + REG_47 which AF source the chip routes + REG_64 a level it displays + +**No audio samples exist anywhere in the MCU's address space.** There is nothing to +capture, nothing to play, and nothing for a browser permission to carry. Generating +sound would be inventing data the firmware never produced — the same line as the +analogue RF limit. + +What is real is the *intent*. `TYPE_UVK5_AUDIO` watches PA8 and exposes read-only +`speaker-on`; the UI shows a speaker glyph and `/api/status` reports `speaker`. +Read-only on purpose: a writable one would only let a test lie to itself. A unit test +also asserts the page never asks for audio permission — no `getUserMedia`, no +`AudioContext`, no `