Transcription stops listening randomly during Google Meet calls

[hyper-charlie]

Description

Listening/transcription randomly stops during Google Meet calls, degrading app usability.

Environment

• Platform: macOS 26.3.0
• App Version: 1.0.6
• Build: 9820787
• Locale: en-US
• LLM: Local LLM

Steps to Reproduce

1. Start a Google Meet call
2. Enable transcription with local LLM
3. Listen to/transcribe the meeting

Expected Behavior

Transcription should continue uninterrupted throughout the meeting.

Actual Behavior

Listening stops randomly at unpredictable intervals during the meeting.

Additional Context

• Occurs on Google Meet specifically
• Using local LLM (not cloud-based)
• Happens on macOS 26.3
• Frequency: Intermittent (not consistent)

[devin-ai-integration]

Codebase Exploration: Transcription Stops During Google Meet

I explored the codebase to identify the relevant components and potential causes. Here are my findings.

---

Relevant Files & Components

Listener Plugin (actor system orchestrating audio capture + STT):

• plugins/listener/src/actors/session.rs — Session supervisor (RestForOne strategy, max 3 restarts in 15 sec)
• plugins/listener/src/actors/root.rs — Root actor; emits Inactive event when supervisor terminates/fails
• plugins/listener/src/actors/source/stream.rs — Audio stream loop (run_stream_loop); reports fatal failure on mic/speaker stream end
• plugins/listener/src/actors/source/pipeline.rs — Audio pipeline (Joiner, AEC, VAD mask, amplitude, buffering to ListenerActor)
• plugins/listener/src/actors/listener/mod.rs — ListenerActor; handles StreamEnded, StreamError, StreamTimeout by stopping itself
• plugins/listener/src/actors/listener/stream.rs — process_stream: 15-minute timeout (LISTEN_STREAM_TIMEOUT) per response
• plugins/listener/src/actors/listener/adapters.rs — WebSocket connection setup with 5-second connect timeout

Audio Capture (macOS):

• crates/audio/src/speaker/macos.rs — CoreAudio aggregate device + process tap; ring buffer with drop tracking
• crates/audio/src/speaker/mod.rs — SpeakerStream wrapping platform stream
• crates/audio/src/mic.rs — Mic input via cpal

Device Monitoring:

• crates/device-monitor/src/macos.rs — CoreAudio property listeners for default device changes
• plugins/listener/src/actors/source/mod.rs:76-87 — DeviceChangeWatcher stops SourceActor on DefaultInputChanged

Local STT:

• plugins/local-stt/src/server/internal.rs — In-process Whisper.cpp Axum server
• plugins/local-stt/src/server/supervisor.rs — STT supervisor (max 100 restarts in 3 min)

WebSocket Client:

• crates/owhisper-client/src/live.rs — WebSocket connection to STT server with keepalive
• crates/ws-client/ (referenced) — Underlying WebSocket transport

Frontend State:

• apps/desktop/src/store/zustand/listener/general.ts — Handles lifecycle events; transitions to inactive when session ends

---

Potential Causes (Most Likely → Less Likely)

1. Google Meet Triggering Audio Device Switches

DeviceChangeWatcher (source/mod.rs:76-87) listens for DefaultInputChanged and stops the SourceActor when it fires. Google Meet may periodically change audio routing (e.g., activating/releasing mic, switching to "Meet audio"), which would:

• Stop SourceActor → RestForOne restarts ListenerActor + RecorderActor
• If this happens >3 times in 15 seconds → supervisor terminates → session ends

The supervisor config at session.rs:41-48:

max_restarts: 3,
max_window: Duration::from_secs(15),

2. Speaker Stream Ending Unexpectedly

In source/stream.rs:251-257, if the speaker stream returns None, it's treated as a fatal error (speaker_stream_ended), stopping the SourceActor. Google Meet's audio output might momentarily stop (e.g., participant mutes, screen share transitions), causing the CoreAudio process tap to signal end-of-stream.

3. Local Whisper Backpressure / Slow Processing

When using local LLM, the in-process Whisper server (internal.rs) processes audio synchronously. If it can't keep up:

• The audio channel (tokio::sync::mpsc::channel(32) in adapters.rs:136/208) fills → try_send drops messages
• The AudioBuffer in pipeline.rs overflows at 150 chunks → audio is lost
• In extreme cases, the WebSocket connection could time out

4. WebSocket Connection Drop to Local STT

If the local Whisper server encounters an error during processing, it sends a ServerError message to the InternalSTTActor, which returns Err from handle(), causing the actor to fail. The STT supervisor would restart it, but the ListenerActor's WebSocket connection to the old server port would be broken, triggering StreamEnded → actor stop.

---

Recent Relevant Commits

Commit	Description	Relevance
bf9c7b835	Fix MicStream read_data accumulation + bounded channels in ws-utils	Fixed memory leak in mic stream; bounded WebSocket channels to prevent backpressure
a8fdf03d7	Break send loop after finalize to prevent keepalive race	Fixed race condition where keepalive messages were sent after finalize
5b6d0859f	Enable AEC	Added acoustic echo cancellation to pipeline, which could affect processing latency

---

Suggested Investigation

1. Check logs for default_input_changed_restarting_source — Would confirm device-switch-triggered restarts
2. Check logs for session_supervisor_terminated / session_supervisor_failed — Would confirm supervisor exhaustion
3. Check logs for speaker_stream_ended or mic_stream_ended — Would confirm audio stream drops
4. Check for samples_dropped warnings — Would indicate ring buffer overflow from slow processing

Additional Information Needed

• Does the user see any error message in the UI when transcription stops? (lastError in the frontend state)
• Does the amplitude indicator (waveform) also stop, or just the transcription text? (Distinguishes audio capture failure vs. STT processing failure)
• Which local STT model is being used? (Larger models = slower processing = more backpressure)
• Is the issue specific to Google Meet, or does it also occur with other apps like Zoom/Teams?