Performance reports

Sync 1080p60: multi-consumer concurrent capture and zero-starvation qualification

22 September 2026 · Research report · Multi-consumer concurrent capture stress, seqlock reader consistency, and zero-starvation qualification

Decision: Retain the monotonic demand heartbeat compare-and-swap loop and the decoupled multi-sink acceptance contract across all platforms. Under sustained 1080p60 workload (1920×1080 uncompressed BGRA8 at 60.0 frames/s), dual concurrent ingestion (CoreMediaIO DAL virtual camera client + packaged Electron desktop shared memory reader) and triple concurrent ingestion (CoreMediaIO DAL virtual camera client + 2× concurrent shared memory readers) demonstrated zero starvation, zero torn reads, and zero dropped frames across all active readers. In the asymmetric disconnect evaluation, when the CoreMediaIO DAL virtual camera consumer terminated at T=25 s, the surviving shared memory consumer delivered 60.0 FPS with 0 low-rate intervals (<50 FPS) and zero backpressure through T=35 s. Under 3× concurrent consumer load, the pipeline delivered 180.61 aggregate unique frames per second (1,498 MB/s aggregate frame memory throughput) with 0 seqlock retries across 5,414 total frame reads. These results satisfy all qualification criteria for Priority 7 of the research roadmap. E1 E2

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

1. Question and design

Noisedeck Sync provides video output to external client applications through two parallel interfaces: an OS-level virtual camera extension (CoreMediaIO DAL on macOS, DirectShow/Media Foundation on Windows) and a local shared memory ring buffer (/tmp/SyncCamera.frames on macOS/Linux, named shared memory sections on Windows). In professional broadcasting and generative performance setups, users frequently run both consumer pathways simultaneously: for example, OBS Studio or Zoom ingests frames from the virtual camera while the Noisedeck packaged Electron desktop app reads the low-latency shared memory stream for local preview and recording.

Prior to this qualification, concurrent multi-consumer capture suffered from two latent concurrency hazards:

1. Demand heartbeat overwrites: Readers maintain active frame generation in syncd by updating a 64-bit microsecond timestamp (last_demand_us) in the ring buffer header. In naive implementations using relaxed stores, concurrent readers stamping demand at slightly diverging timestamps could overwrite a newer timestamp with a lagging one, risking spurious publisher shutdown.
2. Coupled sink backpressure: In CmioCameraSink::submit(), frame acceptance previously depended exclusively on CoreMediaIO queue acceptance (detail::submit_cmio_frame). If an external virtual camera client disconnected, stalled, or suffered backpressure, submit() returned Rejected, causing the publisher to throttle or discard frames despite an active shared memory consumer requesting full 60 FPS delivery.

This research evaluates two structural fixes: (1) an atomic monotonic compare-and-swap (CAS) loop for demand heartbeat recording, ensuring last_demand_us advances monotonically regardless of reader interleaving, and (2) decoupled multi-sink status evaluation returning CameraSinkSubmit::Accepted whenever either the shared memory ring buffer or the virtual camera sink accepts the frame. E1 E3

Table 1. 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 multi-consumer harness orchestrates concurrent consumers across distinct process boundaries:

1. Monotonic Demand CAS Loop: In FrameRingReader::record_demand(now_us), the atomic store is replaced with:

   uint64_t current = header->last_demand_us.load(std::memory_order_relaxed);
   while (now_us > current &&
          !header->last_demand_us.compare_exchange_weak(
              current, now_us,
              std::memory_order_release,
              std::memory_order_relaxed)) {
       // Retry until current reflects equal or newer timestamp
   }

   This guarantees that concurrent readers stamping heartbeats at varying wall-clock intervals can never overwrite a newer timestamp with an older one.
2. Dual-Dispatch Decoupling: In CmioCameraSink::submit(), the frame is written to the shared memory ring buffer (ring_writer->write(...)) and submitted to CoreMediaIO (detail::submit_cmio_frame(...)). Frame acceptance evaluates:

   bool wrote_any = wrote_shm || (cmio_status == CameraSinkSubmit::Accepted);
   return wrote_any ? CameraSinkSubmit::Accepted : CameraSinkSubmit::Rejected;

   This decouples shared memory consumers from virtual camera client lifecycle.
3. Concurrent Verification Harness: Orchestrated by sync-experiments/2026-09-22-1080p60-multi-consumer-stress/run-experiment.mjs, managing daemon lifecycle, paced producer dispatch, and independent capture consumers with arrival JSONL recording.

4. Paired results

Table 2. Multi-consumer capture performance across evaluated arms

Under 3× concurrent consumer stress (Arm 3), the pipeline sustained 61.00 FPS on the virtual camera client and 59.79 / 59.82 FPS on the two 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.75 ms on shared memory consumers and 2.98 ms on the virtual camera consumer. All 5,414 read operations across the 3 consumers completed with zero seqlock retries and zero torn reads. E1

Figure 1. Multi-consumer arrival timing and zero-starvation verification. Top panel: Arm 2 asymmetric disconnect where CMIO consumer terminates at T=25 s while SHM reader continues uninterrupted at 60.0 FPS through T=35 s. Bottom panel: Arm 3 triple concurrent stress demonstrating simultaneous 60 FPS delivery across all three consumers. Full-size SVG figure.

5. Product verification

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

In Arm 2, the AVFoundation virtual camera consumer was intentionally terminated at T=25 s while the paced producer and shared memory consumer ran through T=35 s. Following the abrupt exit of the CMIO 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 decoupling 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. Shared memory readers achieved median arrival intervals of 16.70–16.73 ms with p95 intervals bounded at 18.08–18.16 ms, reflecting consistent 60 Hz frame pacing. CoreMediaIO DAL virtual camera clients achieved median intervals of 16.62–16.65 ms with p95 bounded at 20.87–21.28 ms. E1

7. Diagnostic results

Table 5. Diagnostic findings and architectural implications

8. Decision

Retain the multi-consumer concurrent capture fixes across Noisedeck Sync:

1. Retain the atomic monotonic compare-and-swap loop in FrameRingReader::record_demand in native/src/camera/frame_ring.cpp.
2. Retain the dual-dispatch acceptance check evaluating both shared memory ring buffer status and CoreMediaIO queue status in CmioCameraSink::submit in native/src/platform/macos/cmio_camera_sink.mm.
3. Retain unit and concurrency test coverage in native/test/camera/frame_ring_test.cpp.

All qualification criteria for Priority 7 are satisfied. Priority 7 is marked complete. The research roadmap advances to Priority 8 (Windows FSCS Client Concurrency Qualification).

9. Limits

Empirical testing was conducted on Apple M4 hardware under macOS 15.3.1 using the CoreMediaIO DAL virtual camera plugin and POSIX shared memory ring buffer. Concurrency qualification on Windows under the Frame Server Camera Stream (FSCS) proxy and named shared memory sections will be evaluated under Priority 8.

10. Reproducibility

All test runs, raw metrics, and source configurations are archived in the flat report bundle. The harness scripts and test data are stored in sync-experiments/2026-09-22-1080p60-multi-consumer-stress/.

Evidence references

• [E1] Measurements bundle: measurements.json and raw findings: findings.json in the published report archive.
• [E2] Multi-consumer benchmark harness: sync-experiments/2026-09-22-1080p60-multi-consumer-stress/run-experiment.mjs.
• [E3] Frame ring implementation: native/src/camera/frame_ring.cpp and macOS sink: native/src/platform/macos/cmio_camera_sink.mm.