Performance reports

Sync 1080p60: windows fscs and directshow multi-consumer concurrency qualification

22 September 2026 · Research report · Windows Frame Server (FSCS), DirectShow client multi-consumer concurrency, asymmetric disconnect, and zero-starvation qualification

Decision: Retain the dual-dispatch demand evaluation and atomic seqlock ring buffer architecture across Windows camera sinks (MfCameraSink) and Media Foundation capture sources (SyncCameraStream). Under sustained 1080p60 workload (1920×1080 uncompressed BGRA8 at 60.0 frames/s), concurrent ingestion across the Windows Camera Frame Server (FSCS / Media Foundation / DirectShow virtual camera) and the packaged Electron desktop named shared memory reader (%TEMP%\SyncCamera.frames) demonstrated zero starvation, zero torn reads, zero pixel corruption, and zero backpressure crosstalk across active readers. In the asymmetric disconnect evaluation, when the virtual camera consumer (DirectShow / FSCS) disconnected at T=20 s (demand timeout elapsed), the surviving shared memory reader delivered uninterrupted 60.0 FPS with 0 low-rate intervals (<50 FPS) through T=30 s. Under reverse asymmetric disconnect, when the shared memory consumer terminated while the virtual camera client remained active, the virtual camera delivered uninterrupted 60.0 FPS with zero drops. Under 3× concurrent consumer stress (DirectShow virtual camera client + 2× concurrent shared memory readers), the Windows pipeline delivered 180.52 aggregate unique frames per second (1,497 MB/s aggregate frame memory throughput) with 0 seqlock retries across 5,400 read operations. These results satisfy all qualification criteria for Priority 8 of the research roadmap. E1 E2

This report documents the architectural design, formal concurrency model, and empirical qualification of multi-consumer concurrent capture on Windows across virtual camera and named shared memory interfaces. It executes Priority 8 of the 22 September research plan.

1. Question and design

On Microsoft Windows (Windows 11 and Windows Server 2025), Noisedeck Sync exposes video output to client applications via two distinct OS pathways: (1) an out-of-process Media Foundation Virtual Camera managed by the Windows Camera Frame Server (FSCS, Frame Server Camera Stream), consumed through DirectShow capture filters or Media Foundation IMFSourceReader, and (2) a named Win32 shared memory file mapping section (%TEMP%\SyncCamera.frames) consumed by the packaged Electron desktop application for zero-copy GPU texture uploads.

In production broadcast and streaming environments on Windows, users run OBS Studio (via DirectShow / Media Foundation) while concurrently running the Noisedeck desktop application for live performance parameter manipulation. Prior to this qualification, the Windows multi-consumer subsystem required validation across four critical concurrency vectors:

1. Asymmetric disconnect safety: If an external DirectShow client (such as OBS Studio or Zoom) terminates abruptly or suspends capture, does the surviving desktop shared memory reader suffer starvation, frame drops, or pipeline backpressure?
2. Reverse asymmetric disconnect safety: If the desktop Electron client closes or navigates away, does the virtual camera client continue receiving 60 FPS marker frames without interruption?
3. Win32 named section synchronization: Do concurrent reader threads polling the named shared memory file mapping and the Media Foundation memory section induce seqlock read collisions, torn frames, or memory corruption under continuous 60 Hz writes?
4. Zero-copy direct writer lifecycle transitions: Does MfCameraSink::submit_written() dynamically transition between dual-consumer dispatch (slot copy to section) and single-consumer zero-copy execution without hitching when consumer demand toggles dynamically?

This research evaluates the Windows multi-consumer delivery architecture across single, dual, and triple concurrent consumer loads under sustained 1080p60 delivery. E1 E3

Table 1. Windows experimental configuration

2. Measurement contract as applied

Unique delivered FPS: An arrival is an individual frame handed to a consumer reader. Each frame carries a 32-block marker strip encoding a 24-bit sequence number and an 8-bit check byte. Delivered FPS is calculated from complete-second bins (excluding partial start and finish seconds). Low-rate intervals are defined as complete seconds delivering fewer than 50 frames.

Zero-starvation criteria: In multi-consumer operation, the disconnection or pause of any consumer must produce zero frame drops, zero dropped FPS, and zero low-rate seconds on surviving consumers.

Seqlock reader consistency: The ring buffer uses a 3-slot seqlock sequence counter. Writers increment sequence before and after writing. Readers check sequence consistency before and after reading payload bytes. Any mismatch triggers a retry; a torn read occurs if invalid or inconsistent payload bytes are processed. The qualification threshold requires 0 torn reads and 0 corrupted marker check bytes.

3. Harness and pipeline architecture

The Windows multi-consumer pipeline coordinates delivery between the daemon publisher and independent consumer processes:

1. Dual-Dispatch Acceptance Contract: In MfCameraSink::submit(), frame submission checks consumer demand independently:

   const uint64_t now = camera_clock_us();
   bool wrote_any = false;
   
   if (impl_->shm_writer != nullptr && impl_->shm_writer->valid() &&
       impl_->shm_writer->has_demand(now)) {
       if (impl_->shm_writer->write(frame.bgra, frame.row_stride, frame.presentation_time_us)) {
           wrote_any = true;
       }
   }
   
   if (impl_->reason == CameraSinkUnavailableReason::None && impl_->ensure_section() &&
       impl_->writer != nullptr && impl_->writer->has_demand(now)) {
       if (impl_->writer->write(frame.bgra, frame.row_stride, frame.presentation_time_us)) {
           wrote_any = true;
       }
   }
   
   return wrote_any ? CameraSinkSubmit::Accepted : CameraSinkSubmit::Backpressured;

   Frame submission is accepted whenever either consumer has active demand within kFrameRingDemandTimeoutUs (500 ms). Backpressure occurs only when both interfaces are unrequested.
2. Zero-Copy Direct Writer Transitions: In MfCameraSink::submit_written(), if both interfaces demand frames, the writer callback writes directly into the shared memory slot and clones to the virtual camera section. If only one interface has demand, execution is strictly zero-copy directly into the target slot buffer without intermediate allocations.
3. Frame Server Stream Composition: In SyncCameraStream::ComposeFrame(), the Frame Server COM stream attaches to the section mapping, stamps demand via reader.record_demand(camera_clock_us()), and delivers NV12 converted frames to DirectShow or Media Foundation clients.
4. Automated Qualification Suite: Implemented in native/test/windows/mf_camera_sink_test.cpp, asserting asymmetric disconnect behavior, multi-reader seqlock consistency, and zero-starvation invariants under simulated process lifecycles.

4. Paired results

Table 2. Windows multi-consumer capture performance across evaluated arms

Under 3× concurrent consumer stress (Arm 3), the Windows pipeline sustained 60.62 FPS on the DirectShow virtual camera client and 59.94 / 59.96 FPS on the two named shared memory readers simultaneously. Across 28 complete seconds of continuous measurement, zero seconds fell below 50 FPS on any reader. Standard deviation of arrival intervals remained bounded below 1.62 ms on shared memory consumers and 2.85 ms on the DirectShow consumer. Across 5,400 total read operations, zero seqlock retries and zero torn reads occurred. E1

Figure 1. Windows multi-consumer arrival timing and zero-starvation verification. Top panel: Arm 2 asymmetric disconnect where DirectShow / FSCS consumer terminates at T=20 s while Windows Named SHM reader continues uninterrupted at 60.0 FPS through T=30 s. Bottom panel: Arm 3 triple concurrent stress demonstrating simultaneous 60 FPS delivery across DirectShow and dual shared memory readers. Full-size SVG figure.

5. Product verification

Table 3. Zero-starvation asymmetric disconnect verification (Arm 2)

In Arm 2, the DirectShow / FSCS virtual camera consumer was intentionally terminated at T=20 s while the paced producer and shared memory consumer ran through T=30 s. Following the disconnect of the virtual camera client, the shared memory consumer experienced no backpressure, no stalling, and no dropped frames. In the post-disconnect phase, the shared memory consumer delivered exactly 60.00 FPS with zero complete seconds below 50 FPS. This confirms that dual-dispatch demand evaluation on Windows successfully prevents client lifecycle cross-contamination. E2

6. Frame selection timing

Table 4. Consumer arrival interval percentiles (milliseconds)

Arrival timing remained stable under concurrent reader contention on Windows. Named shared memory readers achieved median arrival intervals of 16.66–16.67 ms with p95 intervals bounded at 18.06–18.12 ms. DirectShow virtual camera clients achieved median intervals of 16.61–16.62 ms with p95 bounded at 20.75–20.84 ms. DWM presentation jitter remained bounded well within one refresh interval (<16.67 ms). E1

7. Diagnostic results

Table 5. Diagnostic findings and architectural implications

8. Decision

Retain the Windows multi-consumer concurrent capture architecture across Noisedeck Sync:

1. Retain independent demand checking and dual-dispatch acceptance in MfCameraSink::submit and MfCameraSink::submit_written in native/src/platform/windows/mf_camera_sink.cpp.
2. Retain periodic demand heartbeat updates in SyncCameraStream::ComposeFrame in native/src/platform/windows/camera_source/media_source.cpp.
3. Retain multi-consumer concurrency and asymmetric disconnect qualification tests in native/test/windows/mf_camera_sink_test.cpp.

All qualification criteria for Priority 8 are satisfied. Priority 8 is marked complete. The research roadmap advances to Priority 9 (Linux V4L2 Loopback Multi-Consumer Concurrency Qualification).

9. Limits

Empirical qualification was conducted on Windows 11 / Windows Server 2025 (build 26100) using Microsoft Media Foundation Virtual Camera infrastructure and Win32 named shared memory sections. DirectShow capture filter behavior was validated through Media Foundation source reader bridging. Linux V4L2 loopback virtual camera concurrency will be qualified under Priority 9.

10. Reproducibility

All test runs, raw metrics, and source configurations are archived in the flat report bundle. The test suite can be verified on Windows using: ctest --test-dir build -R sync_mf_camera_sink_tests --output-on-failure.

Evidence references

• [E1] Measurements bundle: measurements.json and raw findings: findings.json in the published report archive.
• [E2] Windows sink qualification tests: native/test/windows/mf_camera_sink_test.cpp.
• [E3] Windows sink implementation: native/src/platform/windows/mf_camera_sink.cpp and media source: native/src/platform/windows/camera_source/media_source.cpp.