Does this cause audio issues with other applications? That's the main concern I have with this. Cause we're kind of holding a resource that we're not actively using, and I suspect that there could be conflicts with other applications who might try to gain that resource potentially like during video calls or other things. Like I know the audio stuff on Mac OS is pretty weird. And we might just need to ultimately write a better set of drivers for Mac OS to solve this problem at the root level, rather than making patches to the application.

but it's more nuanced than just holding a resource because during the 30s idle window, the mic isn't just sitting there dormant. the cpal AudioUnit callback keeps firing every ~30ms, the hardware is actively capturing audio, and run_consumer receives every chunk and it just discards them since recording = false. so there's real CPU / power cost even when idle

for built-in and wired mics, this is mostly fine. CoreAudio shares input access between processes, so zoom / facetime won't conflict. the only downside is unnecessary wake-ups

for bluetooth though (airpods, etc), it's a bigger deal. an active input stream forces macOS into the HFP / SCO profile, which is low quality 16kHz mono for BOTH input and output on that device. so for the full 30 seconds, the user's music or podcast audio quality tanks even though handy isn't actually recording, which isn't ideal

so the tradeoff is 30 seconds of active mic capture + degraded bluetooth audio vs ~1-2 seconds of bluetooth reconnection latency on back-to-back transcriptions. worth it for power users who transcribe rapidly, not worth it for everyone else

some ideas to make this smarter:

1. detect bluetooth via kAudioDevicePropertyTransportType and use a much shorter timeout (5s) vs wired (30s)
2. make it opt-in: off by default, users who hit the bluetooth latency issue can enable it
3. just use a shorter default across the board (10s vs 30s)

i'm leaning toward option 2 since the current behavior (immediate close) is the safe default for all hardware. what do you think

2 is okay. I think we can maybe do this in experimental for now.

I'm also wondering if we should, to fix other issues potentially, just use the devices default sample rate and always down sample. Our pipeline handles this well already I believe and it may improve things more broadly

This change could be done in another pr

2 is okay. I think we can maybe do this in experimental for now.

sounds good, reworked this to be opt-in under experimental (off by default). added a "keep mic open between transcriptions" toggle that only shows when experimental features are enabled. default behavior (immediate close) is unchanged

I'm also wondering if we should, to fix other issues potentially, just use the devices default sample rate and always down sample. Our pipeline handles this well already I believe and it may improve things more broadly

This change could be done in another pr

for the default sample rate idea opened that as a separate PR: #1084