ML — Recording Health Signals
no_audio_detected health signal and unusable-audio detection emitted as a RecordingHealthEvent domain signal.
ML — Recording Health Signals
Owner: ML Engineer Domain: ml Complexity: S Prerequisite: Milestone 04 merged
When this slice is complete, ML detects a window of unusable (silent/no-audio) input during a live session and reports it to Core via POST /meetings/{id}/recording/health with code: "no_audio_detected", so Core can relay a degraded health signal to the client without stopping the recording.
Required Capabilities
- ML detects a configurable window (
ML_NO_AUDIO_WINDOW_SECONDS) of unusable audio input during a live session. - On detection, ML posts
POST /meetings/{id}/recording/health { status: "degraded", code: "no_audio_detected", recoverable: true, ... }to Core.
Dependencies
- Milestone 04 (
live-transcript-to-final-rebuild) must be merged — the live streaming session ML monitors for audio quality.
Domain Notes
The bet suite's own test docstring is explicit that this is a real detection proof, not a Core-side simulation: it streams genuine silent WebM/Opus frames (the exact container shape MediaRecorder produces, generated via ffmpeg) and states "There is deliberately no fallback: if ML stays silent this test fails." This is one of the few ML-domain capabilities in milestones 06–11 with direct, unmocked bet-progress coverage.
Test Cases
Test cases map to tests/bets/meeting-recording/test_milestone_11_recording_hardening.py. Run via ./dev test bet meeting-recording.
| Test | Location | Assertion |
|---|---|---|
test_no_audio_input_warns_or_auto_stops | test_milestone_11 | Streaming ~25s of real silent WebM/Opus frames causes ML to report no_audio_detected via POST /recording/health within the configured no-audio window — the test fails outright if ML never reports it, with no fallback path. |
Completion Checklist
- Code merged and deployed
- Bet progress tests pass (
./dev test bet meeting-recording) - Permanent service tests implemented per testing strategy
- Code review completed
- Testing review completed
- System documentation updated (as applicable)
Core — Recording Limits
max_duration_seconds enforcement, RecordingDurationWarningEvent and auto-stop, session lock preventing a second active recording per user, and the recording_event_history diagnostics table.
Contracts
API contract reference for the Meeting Recording bet — organised by entity, covering REST, WebSocket, and Pub/Sub.