Skip to content

Comments

feat(audio): lazy stream close for bluetooth mic latency#747

Open
VirenMohindra wants to merge 1 commit intocjpais:mainfrom
VirenMohindra:vm/lazy-stream-close
Open

feat(audio): lazy stream close for bluetooth mic latency#747
VirenMohindra wants to merge 1 commit intocjpais:mainfrom
VirenMohindra:vm/lazy-stream-close

Conversation

@VirenMohindra
Copy link
Contributor

@VirenMohindra VirenMohindra commented Feb 9, 2026

Before Submitting This PR

Please confirm you have done the following:

Human Written Description

  • bluetooth microphones (especially airpods) have a 1-2 second activation lag when pressing the transcription shortcut due to CoreAudio device negotiation
  • this keeps the mic stream warm for 30 seconds after recording ends in OnDemand mode instead of closing immediately, eliminating that latency for all recordings after the first one
  • zero UI / settings changes needed

Related Issues/Discussions

Testing

  • record -> stop -> record again within 30s (second should be instant, check logs for "Microphone stream already active")
  • record -> stop -> wait ~35s -> record (should see "Closing idle microphone stream" then fresh open)
  • multiple quick record / stop cycles (stream stays warm throughout)
  • toggle always-on mic on / off while stream is warm (no crashes)
  • switch microphone device while stream is warm (stream reopens on new device)
  • start recording -> cancel -> verify lazy close scheduled
  • test with bluetooth mic if available

AI Assistance

  • AI was used (please describe below)

If AI was used:

  • Tools used: Claude Code
  • How extensively: implementation of the feature based on a pre-planned approach

Screenshots

  • successfully builds locally with reduced latency while using airpods on MacOS
screenshot

keep the mic stream warm for 30s after recording ends in OnDemand mode
instead of closing immediately. eliminates bluetooth device negotiation
latency (500-1400ms) for all recordings after the first one.

uses a generation counter so only the most recent timer thread actually
closes the stream — rapid record/stop cycles stay warm throughout.
@VirenMohindra VirenMohindra marked this pull request as ready for review February 9, 2026 04:49
@cjpais
Copy link
Owner

cjpais commented Feb 10, 2026

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants