Hardware trigger path — press/release events with the mic already open

[kongkang]

Hi — Kang here, founder of ReAI. We build AI-Board-01, a hardware voice input device.
No commercial ask in this post; I'm here because of a shape I keep seeing in your tracker.

Roughly 130 issues in this repo mention the hotkey. The one I read most carefully is #751:
the trigger key showing a delay and dropping opening and closing words, traced to the capture
pipeline waiting on its first real PCM sample. I want to be precise about that — it's a
regression from a specific change in 1.6.6, not evidence that software triggers are broken.
You'll fix it.

What interests me is the shape underneath it. When the trigger is a key on the user's keyboard
and the mic is a separate device, pressing the key is also the moment capture has to become
ready, so readiness and intent land at the same instant and something has to wait. When the key
and the microphone are the same device and the stream is already open, those two are decoupled:
the press and release are just events, and the audio around them already exists.

I have no published latency numbers for our device and I'm not going to claim we're faster than
anything — that's exactly the kind of thing that should be measured together rather than
asserted. What I can offer concretely is the interface: key down/up and mode events plus
standardized audio over USB and Bluetooth, through a Rust crate or a local HTTP/WebSocket
endpoint. Your on-device STT, your enhancement model, your overlay all stay as they are.

Command Mode is the part I'd be most curious about. You describe controlling the Mac by voice
without touching the keyboard — a dial and a mode switch map onto that fairly naturally, and
that's a conversation I'd rather have with you than guess at.

One question: is a hardware input path worth a look? If yes, I'm glad to build a small
reference implementation against your current architecture so you can judge a real diff. If
FluidVoice is deliberately keyboard-only, say so and I'll leave it there.

— Kang, ReAI (ai-board.reai.com)