fix(recording): detect microphone starvation during voip calls

[ManthanNimodiya]

What & Why

When VoIP calls pre-empt hardware microphone capture, synthetic keepalive silence indefinitely masked the stall and reported false recording success. This adds keepalive silence ratio tracking to detect hardware starvation while preserving intentional mute behavior and emits pipeline stall health events.

Changes

• Added is_audio_starved helper to evaluate silence frame dominance ($\ge 80%$) against unmuted capture.
• Tracked interval silence deltas in the microphone monitor loop to emit PipelineHealthEvent::Stalled when starvation persists.
• Added unit tests verifying starvation detection, normal audio preservation, and mute state isolation.

Checklist

• Code builds locally
• Relevant tests pass or added
• Resolves Studio: microphone track is digital silence for the exact duration of a VoIP call, and the recording reports success #2303

Confidence Score: 5/5

The PR appears safe to merge; the previous repeated-event and understated-duration issue is fully addressed.

Findings

1.  Repeated stall events ▶

Fix with agent prompt

### Issue 1
crates/recording/src/sources/microphone.rs:773-781
During one continuous microphone starvation, `high_silence_intervals` remains at or above two, so this block emits another `Stalled` event every five seconds. It also calculates `waited_ms` from only the latest interval's `silence_delta`. Existing telemetry counts each event as a separate capture stall and records the interval-sized duration as the maximum, inflating the stall count while understating how long the microphone was starved. Track the start of the current stall and emit once per sustained stall, or report cumulative elapsed time like the other stall emitters.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

The PR detects microphone starvation when synthetic keepalive silence dominates unmuted capture and emits a single pipeline-stall event for each sustained starvation episode.

• Tracks captured, dropped, and synthetic-silence frame deltas.
• Excludes intentional mute periods from starvation detection.
• The latest revision prevents repeated events and reports elapsed stall duration.
• Adds focused unit coverage for the starvation threshold and mute isolation.

_{Reviews (2) · Last reviewed commit: "fix(recording): track cumulative stall d..."}

[greptile-apps]

Repeated stall events

During one continuous microphone starvation, high_silence_intervals remains at or above two, so this block emits another Stalled event every five seconds. It also calculates waited_ms from only the latest interval's silence_delta. Existing telemetry counts each event as a separate capture stall and records the interval-sized duration as the maximum, inflating the stall count while understating how long the microphone was starved. Track the start of the current stall and emit once per sustained stall, or report cumulative elapsed time like the other stall emitters.

Prompt To Fix With AI

This is a comment left during a code review.
Path: crates/recording/src/sources/microphone.rs
Line: 773-781

Comment:
**Repeated stall events**

During one continuous microphone starvation, `high_silence_intervals` remains at or above two, so this block emits another `Stalled` event every five seconds. It also calculates `waited_ms` from only the latest interval's `silence_delta`. Existing telemetry counts each event as a separate capture stall and records the interval-sized duration as the maximum, inflating the stall count while understating how long the microphone was starved. Track the start of the current stall and emit once per sustained stall, or report cumulative elapsed time like the other stall emitters.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[ManthanNimodiya]

@greptileai