fix(recorder): resolve Windows FFmpeg device enumeration and recording #985
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
FFmpeg on Windows was failing to open recording devices because the device parameter wasn't properly formatted for DirectShow. The issue manifested as "Error opening input file dummy" even though devices were correctly enumerated. Windows DirectShow requires the syntax `audio="Device Name"` where the quotes are part of the DirectShow parameter format, not shell quoting. Previously, the code was wrapping the entire parameter in quotes, producing incorrect syntax like `"audio=Device Name"`. This fix: - Updates formatDeviceForPlatform() to include quotes around the device name: `audio="Device Name"` - Modifies buildFfmpegCommand() to skip adding outer quotes for Windows since DirectShow parameter already includes proper quoting - Maintains existing behavior for macOS and Linux which use different input formats Fixes #973
The Windows device enumeration was failing because the regex pattern didn't match FFmpeg's actual output format. FFmpeg prefixes DirectShow device listings with `[dshow @ 0x...]` but the regex expected lines to start with optional whitespace and a quote. This caused the parser to return zero devices even though FFmpeg successfully enumerated them, leading to the "No recording devices found" error. Updated the regex from: /^\s*"(.+?)"\s+\(audio\)/ To: /\[dshow[^\]]*\]\s+"(.+?)"\s+\(audio\)/ Now correctly matches lines like: [dshow @ 0x...] "Microphone Array (2- Realtek(R) Audio)" (audio) Related to #973
2 tasks
Contributor
🚀 Preview Deployment Ready!Whispering Preview: https://whispering-pr-985.epicenter.workers.dev Worker Name: This preview will be automatically updated with new commits to this PR. Built with commit f80a43c |
…dows FFmpeg was failing to create recording files on Windows because SIGINT often fails due to console signal handling limitations, causing the code to immediately fall back to SIGKILL which abruptly terminates FFmpeg before it can finalize WAV file headers. This change implements a more robust stopping mechanism: 1. On Windows, first sends 'q\n' to stdin (FFmpeg's built-in graceful quit) 2. Waits 500ms for FFmpeg to process the quit command 3. Falls back to SIGINT (which works well on Unix) 4. If SIGINT fails, waits longer on Windows (1000ms vs 500ms) before force kill 5. Extends backup force kill timeout from 1s to 2s when SIGINT succeeds This gives FFmpeg multiple opportunities to properly finalize recordings, preventing "The system cannot find the file specified" errors when trying to read the output file. Related to #973
The previous fix attempted to use stdin to send 'q' for graceful shutdown, but failed because we were only storing the PID and recreating a Child object from it later. When you create a Child from just a PID, stdin is not connected.
Root cause:
- spawn() returns a Child with stdin/stdout/stderr pipes connected
- We stored only process.pid (line 371)
- Later recreated Child from PID: new Child(session.pid) (line 187)
- This new Child has no stdin access, so child.write('q\n') fails
- Falls back to SIGINT which fails on Windows, then SIGKILL
- SIGKILL abruptly terminates FFmpeg before it can finalize WAV files
Solution:
- Keep the original spawned Child object in memory as activeChild
- Use this object (with stdin access) when stopping recording
- Fall back to PID-based Child only if memory copy is lost (e.g., after app refresh)
This ensures stdin write actually works, allowing FFmpeg to shut down gracefully and properly finalize recording files on Windows.
Fixes #973
Major simplification by removing persisted session state and platform-specific logic: **What was removed:** - Persisted session state (sessionState) and localStorage - FfmpegSession schema and arktype validation - Orphaned process cleanup on initialization - getCurrentChild() and clearSession() helper functions - Windows-specific conditional logic in stopRecording - Platform-specific wait times **What was simplified:** - Use simple in-memory variables: activeChild and activeOutputPath - Universal stdin 'q' approach for all platforms (not just Windows) - Consistent stop flow: stdin 'q' → SIGINT → force kill - Cleaner state management in start/stop/cancel operations **Why this is better:** - Less code, easier to understand - No persistence complexity (if app crashes, recording is lost anyway) - stdin 'q' works reliably on all platforms, not just Windows - Removes edge case handling for orphaned processes - Single code path instead of platform-specific branches The recording state is now ephemeral - if the app refreshes during recording, we lose the session. This is acceptable because we can't gracefully recover anyway (stdin is lost, file is incomplete). Related to #973
Pure refactor with no behavior change. Replaces nested try-catch with tryAsync pattern for consistency, removes conditional branching based on SIGINT success, and always schedules backup force kill. Extracts scheduleBackupKill helper function for clarity. Related to #973
Simplifies FFmpeg graceful shutdown by removing stdin 'q' complexity. SIGINT is the standard Unix signal for gracefully stopping processes, and FFmpeg handles it properly on all platforms. Our Tauri send_sigint command already handles cross-platform complexity. This removes the need to preserve stdin access and eliminates nested tryAsync blocks, making the code simpler while maintaining the same graceful shutdown behavior. Related to #973
Restores stdin 'q' as primary shutdown method (most reliable on Windows) with SIGINT as backup. Increases force kill timeout from 2s to 5s and file polling timeout from 3s to 6s to give FFmpeg adequate time to finalize recordings before termination. The previous SIGINT-only approach was causing premature termination on Windows, resulting in missing output files. Related to #973
This fixes the recording stop issue where files were not being created on Windows. Root causes identified: 1. Missing stdin pipe configuration in spawn_command prevented FFmpeg from receiving the 'q' quit command 2. Backup kill closure captured activeChild reference that was immediately nullified 3. GenerateConsoleCtrlEvent doesn't work with CREATE_NO_WINDOW processes Fixes implemented: 1. Added stdin(Stdio::piped()) to spawn_command in command.rs 2. Captured child reference before state clearing in ffmpeg.ts 3. Replaced GenerateConsoleCtrlEvent with TerminateProcess on Windows The shutdown sequence now works: - stdin 'q' provides graceful FFmpeg shutdown - TerminateProcess provides forceful fallback if needed - Backup kill provides safety net with proper reference Files will now be properly finalized when stopping recordings on Windows.
The previous fix captured childToKill but still used activeChild in the tryAsync blocks, causing TypeScript null errors. Now using childToKill consistently throughout the stop sequence.
…ecording Fixes TypeScript null errors by capturing activeChild reference before async operations in both startRecording (line 226) and cancelRecording (line 492).
- Changed pointer comparison from == 0 to .is_null() in graceful_shutdown.rs - Removed unused WhisperEngine import in transcription/mod.rs
This allows us to visually verify: 1. If FFmpeg is actually receiving stdin 'q' command 2. If the process terminates when we press Stop 3. If file is being written before termination Will re-enable after confirming stdin communication works.
The previous approach returned just a PID from Rust, then constructed a new Child(pid) which doesn't have access to the stdin pipe. Now using Tauri's Command.spawn() directly which returns a proper Child object with stdin/stdout/stderr handles intact. This should allow stdin 'q' to actually reach FFmpeg.
Added debug logging to trace: - Whether stdin write is attempted - Whether stdin write succeeds or fails - SIGINT sending - Backup kill scheduling This will help us see exactly what's happening when we try to stop FFmpeg.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR fixes two related issues preventing Windows users from recording audio with FFmpeg.
Issues Fixed
Windows users were experiencing "No recording devices found" errors even though FFmpeg successfully detected their audio devices. The error manifested as
Error opening input file dummyin the logs.Root Causes
There were two problems in the Windows DirectShow integration:
1. Device Parsing Regex Mismatch
The regex pattern for parsing FFmpeg's device enumeration output didn't account for the
[dshow @ 0x...]prefix that FFmpeg adds to each device line.Before:
regex: /^\s*"(.+?)"\s+\(audio\)/This expected lines to start with optional whitespace and a quote.
After:
regex: /\[dshow[^\]]*\]\s+"(.+?)"\s+\(audio\)/Now correctly matches FFmpeg's actual output format:
2. DirectShow Device Parameter Syntax
DirectShow requires a specific parameter format where quotes are part of the parameter syntax, not shell escaping. The code was incorrectly wrapping the entire parameter in additional quotes.
Before:
After:
The
formatDeviceForPlatform()function now includes quotes in the device name (as part of the DirectShow syntax), andbuildFfmpegCommand()skips adding outer quotes for Windows since they're already properly formatted in the parameter.Technical Details
The fix ensures that:
Fixes #973