Sync 1080p60: windows frame server sustained delivery and wasapi loopback
19 September 2026 · Research report · Windows Media Foundation Frame Server 600-second sustained delivery soak and automated WASAPI loopback qualification
Decision: Retain the Windows Media Foundation Frame Server delivery optimizations (1.0 ms multimedia timer interrupt resolution via timeBeginPeriod(1) and converted_dirty_ NV12 dirty caching in SyncCameraStream::WrapAsSample) and the automated CI WASAPI loopback capture infrastructure. In a 600.0-second sustained endurance soak on bare-metal hardware, the Windows camera subsystem delivered 35,998 unique frames out of 36,001 submitted (60.00 mean delivered FPS), with 596 out of 600 individual seconds delivering exactly 60.00 FPS and zero steady-state dropped frames. In continuous integration, the signed VB-Audio Virtual Cable driver successfully synthesized real WASAPI endpoints and qualified continuous 48 kHz stereo audio capture without discontinuities or packet corruption. E1 E2
This report documents the resolution of Priority 3 from the 19 September 2026 research plan, verifying long-duration frame delivery stability and eliminating the Windows CI hardware audio gap.
1. Question and design
Can the Windows Media Foundation virtual camera sustain true 60.00 FPS delivery over 600 continuous seconds under the Windows Camera Frame Server (FSCS.exe) without frame dropping, CPU lockup, or timing jitter? Furthermore, can the headless Windows CI environment reliably qualify physical WASAPI audio capture without attached DAC hardware?
The investigation audits delivery cadence across a 10-minute endurance soak on physical hardware (largeboi-sync-camera), measures per-second frame arrival distributions, diagnoses the root causes of the baseline 57.42 FPS throughput bottleneck, and establishes automated end-to-end WASAPI loopback capture qualification in continuous integration. E1
Table 1. Experimental configuration and platform matrix
| Dimension | Baseline Soak Arm | Optimized Sustained Soak Arm | CI WASAPI Loopback Arm |
|---|---|---|---|
| Host System | Windows 11 Pro Build 26200 (x86_64) | Windows 11 Pro Build 26200 (x86_64) | Windows Server 2025 (GitHub Actions) |
| Hardware Runner | Physical bare-metal (largeboi-sync-camera) | Physical bare-metal (largeboi-sync-camera) | Virtual bare-metal runner instance |
| Driver Subsystem | Media Foundation (SyncCamera.dll) | Media Foundation (SyncCamera.dll) | VB-Audio Virtual Cable (VBAudioVACWDM) |
| Host Service | Windows Camera Frame Server (FSCS.exe) | Windows Camera Frame Server (FSCS.exe) | Windows Audio Service (audiosrv) |
| Timer Resolution | Default Windows tick (15.625 ms) | 1.0 ms multimedia period (timeBeginPeriod) | Default Windows system tick |
| NV12 Cache | Disabled (re-conversion on repeat) | Enabled (converted_dirty_ sequence check) | N/A (Audio capture) |
| Test Duration | 60 seconds | 600 seconds (10 minutes) | 2 seconds (active capture) |
Figure 1. Per-second delivery performance comparing baseline unoptimized throughput against the 600-second sustained soak. Full-size vector diagram.
2. Measurement contract as applied
Sustained delivery contract: Virtual camera must publish 1920 × 1080 progressive frames at 60.00 fps for 600 seconds. Every second must deliver 60 unique frames (±1 frame boundary allowance). Total steady-state dropped frames must equal zero.
Frame server multiplexing: DirectShow and Media Foundation consumers accessing the stream via ksproxy.ax must receive distinct sequence IDs without blocking the pipeline or triggering CPU starvation.
Audio capture qualification: WASAPI backend must detect active capture endpoints in CI, open a 48 kHz stereo stream, ingest 2,000 ms of audio samples with 100% finite floats, and demonstrate zero cursor discontinuities or dropped frames. E2
3. Windows frame server delivery implementation
The Windows camera publishes frames through an in-process COM server (SyncCamera.dll) hosted by FSCS.exe. The daemon and driver communicate through a 3-slot lock-free shared memory ring buffer (Local\io.noisefactor.sync.camera.frame.v1).
When downstream consumers request samples faster than the source framerate, SyncCameraStream::WrapAsSample delivers repeated frames. By caching the converted NV12 buffer and invalidating it only when the ring sequence ID advances (converted_dirty_), repeat sample creation executes in 0.002 ms instead of 4.2 ms. Concurrently, calling timeBeginPeriod(1) configures the Windows scheduler interrupt resolution to 1.0 ms, eliminating timer quantisation slips. E3
4. Sustained 600-second delivery results
Table 2. Quantitative delivery performance comparison
| Metric | Baseline (60s) | Optimized (600s Soak) | Delta | Status |
|---|---|---|---|---|
| Test Duration | 60.0 s | 600.0 s (10 min) | +540.0 s | PASS |
| Submitted Frames | 3,600 | 36,001 | +32,401 | PASS |
| Delivered New Frames | 3,445 | 35,998 | +32,553 | PASS |
| Mean Delivered FPS | 57.42 FPS | 60.00 FPS (59.9967) | +2.58 FPS | PASS |
| Median Delivered FPS | 57.0 FPS | 60.0 FPS | +3.0 FPS | PASS |
| Seconds at Exactly 60 FPS | 0 / 60 (0.0%) | 596 / 600 (99.33%) | +99.33% | PASS |
| Minimum Second FPS | 54 FPS | 59 FPS (boundary only) | +5 FPS | PASS |
| Maximum Second FPS | 59 FPS | 61 FPS (boundary offset) | +2 FPS | PASS |
| Dropped Frames | 155 (4.305%) | 0 steady-state drops | -155 drops | PASS |
| Out-of-Order Frames | 0 | 0 | 0 | PASS |
| CPU Utilization during Delivery | 100% (single core spin) | 1.2% (nominal) | -98.8% | PASS |
Across the 600-second soak, 596 out of 600 seconds delivered exactly 60 new frames. Only four seconds deviated from 60: second 0 delivered 59 frames (8 startup empties during ring initialization), seconds 536 and 537 delivered 61 and 59 frames respectively (a 1-frame timing offset preserving 120 frames across 2 seconds), and second 599 delivered 59 frames at test teardown. E1
5. Automated CI WASAPI loopback qualification
In headless CI runners without physical sound cards, WASAPI previously enumerated zero devices. Integrating the signed VB-Audio Virtual Cable driver (VBAudioVACWDM) via action-vbcable-win synthesizes full input and output audio endpoints in CI.
The qualification probe (scripts/test-windows-audio.ps1) enumerates CABLE Output (VB-Audio Virtual Cable) (WASAPI) at 48,000 Hz stereo. Accommodating the initial AUDCLNT_BUFFERFLAGS_DATA_DISCONTINUITY flag emitted on stream inception prevents spurious aborts. The capture test verifies 2,000 ms of real-time audio acquisition with zero sample corruption, zero dropped frames, and zero cursor discontinuities. E2
6. Root causes and applied remedies
Table 3. Diagnostic findings and permanent engineering resolutions
| Area | Observed Defect | Root Cause | Permanent Engineering Remedy |
|---|---|---|---|
| A: Timer Jitter | FPS dropped to 54–59 with 155 frame losses over 60s. | Default 15.625 ms Windows scheduler interrupt cadence caused 16.66 ms frame deadlines to be missed. | Invoked timeBeginPeriod(1) to set 1.0 ms interrupt resolution in probe and timer threads. |
| B: NV12 Conversion Lockup | 100% CPU core utilization during camera stream reception. | WrapAsSample re-executed full fixed-point BT.709 color conversion on every repeat sample request. | Added converted_dirty_ caching flag; repeat sample queries bypass conversion and return cached NV12 buffer. |
| C: CI Audio Isolation | CI could not test WASAPI capture, reporting 0 devices. | GitHub Actions Windows runners lack physical audio hardware. | Integrated action-vbcable-win in CI to install signed virtual audio cable driver. |
| D: WASAPI Startup Abort | Capture threw "Native audio capture stopped" on virtual endpoint. | WASAPI reports initial buffer discontinuity on startup; RtAudio mapped this to RTAUDIO_INPUT_OVERFLOW. | Updated NativeCapture to consume initial startup discontinuity while maintaining strict steady-state checks. |
7. Related diagnostic results
The 600-second soak demonstrated zero memory growth in FSCS.exe or the probe process over the 10-minute duration. The shared memory demand heartbeat correctly maintained the active streaming state, and upon consumer disconnect, the 1.0 s timeout cleanly idled daemon frame generation. E3
8. Decision
Retain the 1.0 ms multimedia timer resolution setting and the WrapAsSample NV12 dirty cache. Both optimizations are validated as essential to sustained 1080p60 delivery on Windows. Retain the CI virtual audio cable and WASAPI qualification test as permanent automated regression guards. E1 E2
9. Limits
Testing was performed with a single consumer connected to the Windows Camera Frame Server. Multi-client multiplexing with concurrent DirectShow and Media Foundation consumers under sustained endurance load remains to be qualified in subsequent research.
10. Reproducibility
To reproduce the 600-second delivery soak, trigger the camera-delivery.yml GitHub Actions workflow with inputs duration_seconds: 600 and target_fps: 60 on the largeboi-sync-camera runner. To reproduce the WASAPI audio capture qualification, execute powershell scripts/test-windows-audio.ps1 "build/Release" "audio-qualification" on a Windows runner with the VB-Cable driver installed.
Evidence references
- E1. Quantitative delivery measurements and baseline comparison data.
- E2. Diagnostic findings and architectural remediation details.
- E3. Per-second frame delivery timeline vector diagram.
- E4. Sync 1080p60: Windows camera and WASAPI platform parity, 18 September 2026.
- E5. Sync 1080p60: next research plan, 19 September 2026.