Public Access
61 lines
4.4 KiB
Markdown
61 lines
4.4 KiB
Markdown
## Context
|
|
|
|
The Windows microphone source currently creates one NAudio `IWaveIn` for the lifetime of a recording. When the endpoint is unplugged, NAudio reports a WASAPI exception through `RecordingStopped`; the source completes exceptionally, the composite source treats that as fatal, and `MeetingRecordingCoordinator` ends the run. The composite source already tolerates a temporarily quiet microphone by mixing system audio with synthetic silence after its alignment timeout, so recovery can be isolated to the microphone side.
|
|
|
|
The microphone selection provider already re-enumerates active endpoints whenever it creates a capture. Its selection rules ignore an unavailable runtime/configured device and fall back to the current Windows default. The missing behavior is retrying that resolution after an active capture fails.
|
|
|
|
## Goals / Non-Goals
|
|
|
|
**Goals:**
|
|
|
|
- Keep the active meeting run alive when microphone capture fails or stops unexpectedly.
|
|
- Re-resolve the effective microphone on every recovery attempt so another active endpoint can take over.
|
|
- Keep system-loopback audio flowing while microphone recovery is pending.
|
|
- Verify recovery deterministically through the public audio-source contract without physical audio devices.
|
|
|
|
**Non-Goals:**
|
|
|
|
- Recover system-loopback capture failures.
|
|
- Persist or change the user's runtime microphone selection.
|
|
- Add UI, endpoint, or configuration controls for recovery.
|
|
- Splice or manufacture microphone audio for the disconnected interval.
|
|
|
|
## Decisions
|
|
|
|
### Keep retry orchestration outside the NAudio adapter
|
|
|
|
`MicrophoneAudioSource` will own a recovery loop and ask `IMicrophoneDeviceProvider` for a new capture source on each attempt. The Windows provider will continue to own endpoint enumeration and selection, while an NAudio-specific adapter will own one `IWaveIn` lifetime.
|
|
|
|
This keeps device selection and WASAPI details behind a narrow boundary and makes the observable recovery behavior testable with deterministic capture sources. Retrying the same `IWaveIn` instance was rejected because a disconnected WASAPI client is not a reliable basis for endpoint failover.
|
|
|
|
### Treat unexpected completion and capture exceptions as recoverable
|
|
|
|
While the recording cancellation token remains active, microphone-source creation failures, capture exceptions, and clean-but-unexpected capture completion will all trigger another attempt. Cancellation remains the only normal terminal condition for the microphone stream.
|
|
|
|
This deliberately contains microphone failures without changing the composite source's handling of system-audio failures.
|
|
|
|
### Re-resolve after a bounded delay
|
|
|
|
Each recovery attempt will call the provider again after a short fixed delay. Recreating through the provider re-enumerates active devices and applies the existing runtime selection, configured selection, and Windows-default fallback rules. The delay prevents a busy loop while Windows is still updating endpoint state.
|
|
|
|
No new setting is introduced because recovery timing is an internal reliability detail and does not need user tuning for the current scope.
|
|
|
|
### Reuse the composite source's missing-stream behavior
|
|
|
|
The recovering microphone enumerable remains active between attempts instead of completing. The independently pumped system source therefore continues writing chunks, and the composite source's existing alignment timeout mixes those chunks with silent microphone samples until real microphone chunks resume.
|
|
|
|
## Risks / Trade-offs
|
|
|
|
- **Windows endpoint enumeration can lag behind physical disconnects** → Retry through fresh provider calls until the device list and default endpoint stabilize.
|
|
- **A persistent microphone or driver failure can retry indefinitely** → Use a delay, log each failed attempt, and stop immediately when the recording is canceled.
|
|
- **The replacement endpoint can have different native capabilities** → Continue requesting the run's configured PCM format through the same NAudio adapter; failed formats remain recoverable and retryable.
|
|
- **There is an unavoidable microphone gap during failover** → Preserve the meeting and system audio rather than inventing microphone samples; the mixed stream contains silence for the missing microphone interval.
|
|
|
|
## Migration Plan
|
|
|
|
No data or configuration migration is required. Deploy the updated executable normally. Rollback consists of restoring the previous executable; existing meeting artifacts are unaffected.
|
|
|
|
## Open Questions
|
|
|
|
None for this change.
|