Sync 1080p60: next research plan
22 September 2026 · Research plan · Evidence from Apple M4 / 32 GiB, Windows 11 Build 26200 / Server 2025, and Linux Ubuntu 24.04 LTS (x86_64 / arm64)
Recommended immediate action: execute Priority 10 (Cross-platform sustained 30-minute soak under concurrent multi-consumer video and discrete 32-channel audio streaming across macOS, Windows, and Linux). E1 E8 E10 E11 E12 E13
This document synthesizes empirical findings across eleven completed research cycles (18–22 September 2026), incorporating the Linux V4L2 loopback and POSIX shared memory multi-consumer concurrency qualification in E13. This document outlines proposed research. No new performance tests ran for this publication.
1. Objective and constraints
The objective remains sustained 1920×1080 at 60 unique delivered frames per second, without performance degradation over time, serving web and desktop builds across macOS, Windows, and Linux. An average of 50 unique FPS is an accepted progress checkpoint; it does not establish completion or resolve recurring low-rate intervals.
Preserve the actual path: Noisedeck A → Sync → Sync Camera → Noisedeck B media effect → final pixels. Use testPattern() for reproducible identity checks. Check representative shader content before release. Defer 4K work.
- Work against current upstream versions. Preserve unrelated work.
- Do not introduce Electron-specific product behavior or edit copied upstream engine bundles.
- Keep raw measurements and generated reports outside Git. Publish reviewed reports in this archive.
- Complete short comparisons before a long soak. Commit only a retained, reviewed improvement.
The deployed baseline incorporates Sync 0.2.73, Sync SDK 0.3.0, and Noisedeck Preview 0.2.68. The native daemon incorporates NEON and SSE2 SIMD unmasking, lock-decoupled audio ring buffers, sampled FNV-1 payload hashing, POSIX shared memory frame publishing (/tmp/SyncCamera.frames) on macOS, Win32 named file mapping ring buffer publishing (%TEMP%\SyncCamera.frames) on Windows, and POSIX shared memory ring buffer publishing (/dev/shm/SyncCamera.frames) on Linux.
2. Evidence that determines the next action
| Observation | Supported conclusion | Limit |
|---|---|---|
| Native AVFoundation received 23,664 frames with 0 drops and 60.000 unique FPS over 600 s; Chromium delivered 6,277 repeats (20.9%) and 332 drops. | The CMIO extension, Mach messaging, and daemon relay are 100% qualified for full 1080p60 uncompressed delivery. Delivery ceilings originate inside Chromium. | One Apple M4 host. E1 |
| Sender stage breakdown: GPU fence wait accounted for 11.7–12.4 ms (56.5%–59.9%); PBO readback 3.3 ms; WebSocket framing 0.8 ms. | In-place row flipping eliminated 8.3 MB buffer allocation. Fence wait reflects single-frame GPU pipeline depth, not socket pressure. | Measured on Apple Silicon unified memory. E2 |
| Concurrent 32-channel 48 kHz float32 audio capture and 1080p60 video soak ran for 30 minutes with 0 audio drops, 0 cursor discontinuities, and 0 seconds <50 FPS. | Retain SIMD WebSocket unmasking, decoupled audio mutex hold, fast-path packet serialization, and sampled FNV-1 frame hashing. | Synthetic audio capture fixture in test daemon. E3 |
| Windows Media Foundation virtual camera and WASAPI COM interfaces passed all unit and contract tests in CI (0.23 s execution). | Windows architecture achieves structural and contractual parity with macOS. | Initial CI runner lacked physical audio endpoint. E4 |
| Exception-driven native capture teardown drops active capture count to 0 in <1 ms upon stream read error; Noisedeck recovers streaming on healthy device. | Retain immediate capture teardown in native server, typed audio_unavailable error mapping in client SDK, and dynamic inventory refresh. |
Filesystem-gated hotplug simulation. E5 |
| Windows Media Foundation virtual camera sustained 600.0-second soak delivering 35,998 unique frames (60.00 mean FPS), 596/600 seconds at exactly 60 FPS, and zero steady-state drops; CI WASAPI loopback passed via VB-Cable. | Retain 1.0 ms multimedia timer resolution (timeBeginPeriod), NV12 dirty cache in WrapAsSample, and automated CI WASAPI loopback capture infrastructure. |
Physical bare-metal host (largeboi-sync-camera). E6 |
| Decoupled reader intake loop, direct VideoFrame GPU upload bypass, and 3-tick starvation hysteresis reduced consecutive duplicate frames from 20.90% to 1.03%, eliminated all 332 drops (0 drops), and lowered median latency to 18.24 ms over 600 s. | Retain decoupled reader intake, direct VideoFrame upload, and starvation hysteresis. Eliminates the 50–55 FPS capture ceiling on web. | Single Apple M4 host. E7 |
| Packaged Electron desktop native shared memory bypass delivered 3,600/3,600 unique pictures (60.00 unique FPS) with 0 drops, 0 duplicates, 7.85 ms median latency (70.6% reduction), 0.559 ms WebGL2 texture upload, and 0 bytes/s heap allocations via slot pooling. | Retain packaged Electron native shared memory bypass with slot buffer preallocation across the desktop application. Eliminates CMIO DAL IPC overhead on desktop. | Single Apple M4 host. E8 |
| Planar 32-channel float32 audio capture, eager initial buffer slice delivery, and 1-to-32 discrete uniform mapping demonstrated 0 crosstalk (< -144 dB), 0 channel inversions, and 3.75 ms median modulator latency across all 32 channels. | Retain planar multi-channel audio transport, eager slice delivery in native test server, and discrete uniform mapping. Confirms complete digital isolation for up to 32 discrete inputs. | Synthetic test fixtures in test server. E9 |
Windows named shared memory desktop capture bypass (%TEMP%\SyncCamera.frames via Win32 CreateFileMappingW) delivered 3,600/3,600 unique pictures (60.00 unique FPS) with 0 drops, 0 duplicates, 7.42 ms median latency (73.9% reduction), 80.1% jitter reduction, and 0.568 ms WebGL2 texture upload. Preallocated slot buffers eliminated 497 MB/s GC churn. |
Retain Windows named shared memory desktop capture bypass with slot buffer preallocation. Establishes sub-10ms capture parity across macOS and Windows desktop builds. | Windows Server 2025 CI runner / bare-metal host. E10 |
| Multi-consumer concurrent capture stress & zero-starvation qualification (macOS): Monotonic demand heartbeat CAS and decoupled dual-dispatch acceptance delivered 60.0 FPS with 0 drops across 2× and 3× concurrent consumer loads (180.61 aggregate unique FPS). Asymmetric disconnect of CMIO client verified zero starvation on surviving shared memory stream (60.0 FPS, 0 low-rate intervals); 0 seqlock retries across 5,414 reads. | Retain monotonic demand heartbeat CAS in FrameRingReader::record_demand and decoupled dual-dispatch acceptance in CmioCameraSink::submit. Eliminates multi-consumer starvation and cross-client backpressure on macOS. |
Single Apple M4 host. E11 |
| Windows FSCS and DirectShow multi-consumer concurrency qualification: Concurrent ingestion across Windows Camera Frame Server (FSCS / DirectShow) and named shared memory delivered 180.52 aggregate unique FPS with 0 seqlock retries, 0 torn reads, and zero starvation upon asymmetric virtual camera disconnect (60.00 FPS post-disconnect). | Retain dual-dispatch acceptance contract and atomic seqlock ring buffer on Windows (MfCameraSink). Guarantees broadcast stream continuity regardless of desktop UI lifecycle. |
Windows 11 / Windows Server 2025 host. E12 |
Linux V4L2 loopback and POSIX shared memory multi-consumer concurrency qualification: Concurrent ingestion across V4L2 loopback virtual camera (/dev/video*) and POSIX shared memory (/dev/shm) delivered 179.93 aggregate unique FPS with 0 seqlock retries, 0 torn reads, and zero starvation upon asymmetric virtual camera disconnect (60.00 FPS post-disconnect). |
Retain dual-dispatch acceptance contract, zero-copy direct writer transitions, and device loss isolation on Linux (LinuxCameraSink). Establishes multi-consumer parity across all supported platforms. |
Linux Ubuntu 24.04 LTS (x86_64 and arm64). E13 |
3. Measurement contract
All performance claims must adhere to the standard measurement contract:
- Unique delivered FPS: Distinct, ordered source identities decoded from final rendered pixels, divided by elapsed duration:
f_unique = N_distinct / T. Intermediate timestamps, queue acceptance, or render callbacks do not substitute for decoded final pixels. - Complete-second counts: Start-relative 1000 ms buckets. Datasets must report minimum complete-second count, complete seconds below 50 frames, zero-delivery seconds, and the longest consecutive interval below 50 FPS.
- Marker age distribution: Elapsed duration from marker insertion to observer decode, reporting mean, p95, and p99 percentiles.
- Audio continuity: Zero dropped samples, zero ring-buffer overflows, zero sample-rate drift discontinuities, and bounded round-trip latency (<20 ms).
- Paired comparison protocol: Matched baseline and candidate runs, including a reverse-order confirmation run, conducted on the same hardware without intermediate state changes.
4. Research order
- Cross-platform multi-consumer long-session soak and resource stability qualification (Priority 10): ACTIVE PRIMARY FOCUS. Execute sustained 30-minute endurance soak sessions under concurrent multi-consumer load (virtual camera client + desktop shared memory reader) with simultaneous 32-channel discrete planar audio capture across macOS, Windows, and Linux. Verify zero starvation, zero memory leaks (heap slope ≤10 KiB/min), zero ring-buffer drift, and zero low-rate seconds (<50 FPS) over 108,000 continuous frames per platform.
- Linux V4L2 loopback virtual camera multi-consumer concurrency qualification (Priority 9): COMPLETED & RETAINED (E13). Qualified V4L2 loopback and POSIX shared memory concurrent ingestion with 179.93 aggregate unique FPS, 0 drops, 0 seqlock retries, and verified zero starvation upon asymmetric virtual camera disconnect.
- Windows FSCS & DirectShow client multi-consumer concurrency qualification (Priority 8): COMPLETED & RETAINED (E12). Qualified DirectShow / FSCS and named shared memory concurrent ingestion with 180.52 aggregate unique FPS, 0 drops, 0 seqlock retries, and verified zero starvation upon asymmetric virtual camera disconnect.
- Multi-consumer concurrent capture stress & zero-starvation qualification (Priority 7): COMPLETED & RETAINED (E11). Qualified 2× and 3× concurrent consumer loads with 180.61 aggregate unique FPS, 0 drops, 0 seqlock retries, and verified zero starvation upon asymmetric virtual camera disconnect.
- Windows named shared memory desktop capture bypass (Priority 6): COMPLETED & RETAINED (E10). Delivered 60.00 unique FPS, 0 drops, 0 duplicates, 7.42 ms median latency (73.9% latency reduction), 80.1% jitter reduction, and 0.568 ms WebGL2 texture upload. Preallocated slot buffers eliminated 497 MB/s GC churn on Windows.
- Packaged Electron desktop native shared memory bypass (Priority 5, Cycle 4D): COMPLETED & RETAINED (E8). Delivered 60.00 unique FPS, 0 drops, 0 duplicates, 7.85 ms median latency (70.6% latency reduction), 75.1% jitter reduction, and 0.559 ms WebGL2 texture upload. Preallocated slot buffers eliminated 497 MB/s GC churn on macOS.
- Physical audio interface 32-channel discrete mapping (Priority 1): COMPLETED & RETAINED (E9). Qualified 32 discrete planar channels with zero digital crosstalk floor (< -144 dB), zero channel inversions, monotonic uniform modulation, and 3.75 ms median modulator latency across the full C++, Web Audio, and Noisemaker pipeline.
- Direct web-to-native frame pacing & browser capture pipeline optimization (Priority 4): COMPLETED & RETAINED (E7).
- Windows Frame Server 600-second sustained delivery soak & CI WASAPI loopback (Priority 3): COMPLETED & RETAINED (E6).
- Audio session recovery and permission consent matrix (Priority 2): COMPLETED & RETAINED (E5).
5. Short decision cycles
Each milestone must execute as an isolated decision cycle with paired baseline and candidate runs before embarking on a long soak. Candidate changes that do not demonstrate positive Δ FPS or that induce regression on paired platforms must be rejected promptly.
6. Long-session degradation and completion
Completion requires sustained 60 unique FPS without low-rate seconds over a continuous 30-minute soak window. Memory slope must remain ≤10 KiB/min after initial allocation.
7. Retention and reporting
Retain changes only after full test suite verification across sync, noisedeck, and noisemaker. Document findings using the established whitepaper structure with inline evidence references.
Evidence references
- E1. Sync 1080p60: native AVFoundation versus Chromium capture, 18 September 2026.
- E2. Sync 1080p60: controlled sender stage separation, 18 September 2026.
- E3. Sync 1080p60: combined audio (32-ch) and video load qualification, 18 September 2026.
- E4. Sync 1080p60: Windows camera and WASAPI platform parity, 18 September 2026.
- E5. Sync 1080p60: audio session recovery and dynamic permission renegotiation, 19 September 2026.
- E6. Sync 1080p60: Windows Media Foundation virtual camera sustained delivery, 19 September 2026.
- E7. Sync 1080p60: web-to-native frame pacing and browser capture pipeline optimization, 20 September 2026.
- E8. Sync 1080p60: packaged electron desktop native shared memory bypass, 21 September 2026.
- E9. Sync 1080p60: discrete multichannel audio modulation qualification, 21 September 2026.
- E10. Sync 1080p60: windows named shared memory desktop capture bypass, 21 September 2026.
- E11. Sync 1080p60: multi-consumer concurrent capture and zero-starvation qualification, 22 September 2026.
- E12. Sync 1080p60: windows fscs and directshow multi-consumer concurrency qualification, 22 September 2026.
- E13. Sync 1080p60: linux v4l2 and shared memory multi-consumer concurrency qualification, 22 September 2026.