Performance reports

Sync 1080p60: linux v4l2 and shared memory multi-consumer concurrency qualification

22 September 2026 · Research report · Linux Video4Linux2 (V4L2) loopback, POSIX shared memory multi-consumer concurrency, asymmetric disconnect, and zero-starvation qualification

Decision: Retain the dual-dispatch demand evaluation and atomic seqlock ring buffer architecture across Linux camera sinks (LinuxCameraSink) and POSIX shared memory ring writers (FrameRingWriter). Under sustained 1080p60 workload (1920×1080 uncompressed BGRA8 at 60.0 frames/s), concurrent ingestion across the Linux V4L2 loopback virtual camera device (/dev/video*) and the packaged Electron desktop POSIX shared memory ring buffer (/dev/shm/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 (V4L2 loopback) experienced simulated device disconnection (ENODEV) at T=20 s, 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 V4L2 client remained active, the virtual camera delivered uninterrupted 60.0 FPS with zero drops. Under 3× concurrent consumer stress (V4L2 loopback client + 2× concurrent POSIX shared memory readers), the Linux pipeline delivered 179.93 aggregate unique frames per second (1,492 MB/s aggregate frame memory throughput) with 0 seqlock retries across 5,400 read operations. These results satisfy all qualification criteria for Priority 9 of the research roadmap. E1 E2

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

1. Question and design

On Linux (Ubuntu 24.04 LTS), Noisedeck Sync exposes video output to client applications via two distinct OS pathways: (1) a kernel Video4Linux2 loopback virtual camera device (/dev/video*) written through non-blocking asynchronous worker threads using NV12 or YUYV color formatting, consumed by OBS Studio, Chromium, Zoom, and GStreamer, and (2) a POSIX shared memory ring buffer (/dev/shm/SyncCamera.frames) consumed by the packaged Electron desktop application for zero-copy GPU texture uploads via atomic seqlock synchronization.

In production broadcast and streaming environments on Linux, users run OBS Studio (via V4L2 loopback) while concurrently running the Noisedeck desktop application for live visual synthesis and performance monitoring. Prior to this qualification, the Linux multi-consumer subsystem required validation across four critical concurrency vectors:

1. Asymmetric disconnect safety: If an external V4L2 client (such as OBS Studio or GStreamer) terminates abruptly or unloads the loopback module, 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. POSIX shared memory ring synchronization: Do concurrent reader processes polling the POSIX shared memory file mapping induce seqlock read collisions, torn frames, or memory corruption under continuous 60 Hz writes?
4. Zero-copy direct writer lifecycle transitions: Does LinuxCameraSink::submit_written() dynamically transition between dual-consumer dispatch (slot copy and NV12 conversion) and single-consumer zero-copy execution without hitching when consumer demand toggles dynamically?

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

Table 1. Linux 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 Linux multi-consumer pipeline coordinates delivery between the daemon publisher and independent consumer processes:

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

   const std::uint64_t now_us = camera_clock_us();
   const bool shm_demand = (impl_->shm_writer != nullptr && impl_->shm_writer->valid() &&
                            impl_->shm_writer->has_demand(now_us));
   const bool v4l2_demand = (impl_->initially_available && impl_->healthy_state.load());
   
   if (!shm_demand && !v4l2_demand) {
     if (impl_->options.metrics != nullptr) impl_->options.metrics->note_camera_backpressure();
     return CameraSinkSubmit::Backpressured;
   }
   
   bool wrote_any = false;
   if (shm_demand) {
     if (impl_->shm_writer->write(frame.bgra, frame.row_stride, frame.presentation_time_us)) {
       wrote_any = true;
     }
   }
   
   if (v4l2_demand) {
     // convert BGRA to NV12 in background queue slot and signal worker thread
     ...
   }
   
   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 LinuxCameraSink::submit_written(), if both interfaces demand frames, the writer callback writes directly into the POSIX shared memory slot and clones to the V4L2 NV12 slot buffer. If only the shared memory interface has demand, execution is strictly zero-copy directly into the target slot buffer without intermediate allocations or color conversions.
3. Device Loss Isolation & Auto-Recovery: When V4L2 encounters an unrecoverable write error (ENODEV or EPIPE), LinuxCameraSink immediately marks the V4L2 subsystem unhealthy, isolates the backpressure from the shared memory publisher, and initiates background reconnect attempts with exponential backoff while shared memory streaming continues uninterrupted.
4. Automated Qualification Suite: Implemented in native/test/linux/camera_sink_test.cpp, asserting asymmetric disconnect behavior, multi-reader seqlock consistency, and zero-starvation invariants under simulated device loss and reader contention.

4. Paired results

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

Under 3× concurrent consumer stress (Arm 3), the Linux pipeline sustained 60.10 FPS on the V4L2 loopback virtual camera and 59.93 / 59.90 FPS on the two POSIX 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.68 ms on shared memory consumers and 2.88 ms on the V4L2 consumer. Across 5,400 total read operations, zero seqlock retries and zero torn reads occurred. E1

Figure 1. Linux multi-consumer arrival timing and zero-starvation verification. Top panel: Arm 2 asymmetric disconnect where V4L2 loopback consumer disconnects at T=20 s while Linux POSIX 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 V4L2 loopback 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 V4L2 loopback consumer was intentionally disconnected at T=20 s (simulating kernel device loss or crash) 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 Linux 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 Linux. POSIX shared memory readers achieved median arrival intervals of 16.66 ms with p95 intervals bounded at 18.10–18.24 ms. V4L2 loopback virtual camera clients achieved median intervals of 16.61–16.62 ms with p95 bounded at 19.95–20.15 ms. System 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 Linux multi-consumer concurrent capture architecture across Noisedeck Sync:

1. Retain independent demand checking and dual-dispatch acceptance in LinuxCameraSink::submit and LinuxCameraSink::submit_written in native/src/platform/linux/camera_sink.cpp.
2. Retain POSIX shared memory ring buffer integration in native/include/sync/camera/frame_ring.hpp.
3. Retain multi-consumer concurrency and asymmetric disconnect qualification tests in native/test/linux/camera_sink_test.cpp.

All qualification criteria for Priority 9 are satisfied. Priority 9 is marked complete. The research roadmap advances to Priority 10 (Cross-Platform Multi-Consumer Long-Session Soak and Resource Stability Qualification).

9. Limits

Empirical qualification was conducted on Linux Ubuntu 24.04 LTS (kernel 6.8, x86_64 and arm64) using the v4l2loopback virtual camera infrastructure and POSIX shared memory ring buffers in /dev/shm. Extended 30-minute cross-platform soak under concurrent load will be qualified under Priority 10.

10. Reproducibility

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

Evidence references

• [E1] Measurements bundle: measurements.json and raw findings: findings.json in the published report archive.
• [E2] Linux sink qualification tests: native/test/linux/camera_sink_test.cpp.
• [E3] Linux sink implementation: native/src/platform/linux/camera_sink.cpp and shared memory ring: native/include/sync/camera/frame_ring.hpp.