Performance reports

Sync 1080p60: multi-consumer endurance soak and resource stability qualification

22 September 2026 · Research report · Multi-consumer concurrent endurance soak, memory slope qualification, and 32-channel discrete audio stability

Decision: Retain the decoupled multi-sink acceptance contract, user-interactive thread QoS, 256 KiB socket write/read buffers, and non-blocking capture mutex locking across all production platforms. Under sustained 30-minute endurance soak (1,800.0 s, 108,000 target frames at 1920×1080 BGRA8 60.0 FPS) under concurrent triple-consumer load (CoreMediaIO DAL virtual camera client + desktop shared memory direct reader + 32-channel discrete planar audio capture client at 48 kHz), the pipeline delivered 60.99 unique FPS via AVFoundation, 59.98 unique FPS via shared memory, and transferred 2,709,941,760 audio samples across 265,575 batch reads with zero server-reported drops, zero cursor discontinuities, and zero nonfinite samples. Memory telemetry demonstrated complete resource stability: physical footprint began at 5.72 MiB, stabilized at 39.20–47.60 MiB (reflecting the 8 MiB CMIO buffer pool cache cycling), and exhibited a steady-state regression slope of -181.94 KiB/min, confirming zero memory leaks (≤10 KiB/min threshold). Across 107,964 shared memory frame transfers, zero seqlock retries and zero torn reads occurred. All five qualification criteria for Priority 10 of the research roadmap are fully satisfied. E1 E8 E11 E14

This report documents the empirical qualification of Noisedeck Sync under sustained long-session multi-consumer load, executing Priority 10 of the 22 September research plan (v4).

1. Question and design

In live audiovisual installations, studio streaming broadcasts, and generative performance workflows, Noisedeck Sync operates under continuous multi-consumer stress for extended periods. In these environments, three independent consumer pipelines operate concurrently against a single syncd daemon instance:

1. Broadcast Virtual Camera: External video switchers (e.g. OBS Studio, Zoom, Wirecast) ingest full 1080p60 video via the OS-level virtual camera extension (CoreMediaIO DAL on macOS).
2. Desktop Native Shared Memory: The Noisedeck Electron desktop application ingests the raw frame stream via direct POSIX shared memory (/tmp/SyncCamera.frames) with zero-copy WebGL2 texture upload for local monitoring and recording.
3. Discrete Multichannel Audio: Audio automation tracks stream up to 32 discrete, unmixed channels of 48 kHz 32-bit float audio over authenticated WebSocket IPC for spatial modulation and multi-bus parameter routing.

While short-duration tests (30–60 s) confirmed functional correctness in prior research cycles (E11, E12, E13), long-session operation introduces severe resource stability risks: cumulative memory leakage in buffer queues, socket backpressure accumulation, kernel page cache fragmentation, ring-buffer sequence drift, and audio sample slip under concurrent thread scheduling contention.

This qualification addresses five essential questions:

1. Does concurrent multi-consumer video ingestion induce any frame starvation or low-rate seconds (<50 FPS) over 108,000 continuous frames?
2. Does native process memory exhibit any steady-state positive slope (>10 KiB/min) after startup buffer allocation?
3. Do concurrent shared memory readers encounter seqlock sequence collisions or torn reads over 30 minutes?
4. Does continuous 32-channel audio streaming preserve digital integrity without sample drops, buffer under-runs, or nonfinite IEEE 754 floats?
5. Does loopback IPC round-trip latency remain bounded under sustained heavy multi-stream throughput?

Table 1. Experimental configuration

2. Measurement contract as applied

Measurement follows the strict Sync measurement contract across all three active consumers:

• Unique delivered video FPS: Measured from fully decoded arrival frames at consumer boundaries. Delivered FPS is computed across complete 1000 ms wall-clock bins, excluding startup and teardown seconds. Low-rate seconds are defined as any complete second delivering fewer than 50 frames.
• Memory leak qualification: Process telemetry samples physical footprint (footprint(1)) and resident set size (RSS) every 5,000 ms. Steady-state memory growth is computed via ordinary least-squares linear regression over the final 28 minutes of the soak. Qualification requires a regression slope ≤ 10.0 KiB/min.
• Ring buffer drift & torn reads: The 3-slot ring buffer tracks 64-bit seqlock counters. Readers verify sequence stability before and after copying payload bytes. Qualification requires zero seqlock retries and zero payload check failures.
• Audio stream continuity: Every audio packet is verified for sequential frame numbering, zero gap discontinuities, zero server-reported buffer drops, and finite IEEE 754 sample values across all 32 channels.
• Round-trip latency: Audio request-to-arrival round-trip time (RTT) is recorded per read, reporting median (p50), 95th percentile (p95), 99th percentile (p99), and maximum latency.

3. Harness and pipeline architecture

To ensure high throughput and zero starvation under heavy multi-stream load, four architectural components operate in syncd and the evaluation harness:

1. Non-Blocking Capture Mutex Lock: In native/src/audio_capture.cpp, the audio capture buffer previously relied on a 100-retry spinlock. Under multi-consumer load with high CPU utilization, thread preemption could cause spinlock expiration and dropped frames. This was replaced with an uncontented std::unique_lock<std::mutex>, eliminating spinlock jitter and guaranteeing atomic buffer updates with zero dropped frames.
2. High-Throughput Socket Buffer Sizing: In native/src/server.cpp, socket write queues and read buffers were expanded to 256 KiB, and the libuv TCP receive buffer was set to 4 MiB (uv_recv_buffer_size(&connection->handle, 4 * 1024 * 1024)). This eliminates TCP window clamping during simultaneous 1080p60 frame streaming and 32-channel audio transfer.
3. User-Interactive Thread QoS: In native/src/main.cpp, the daemon process assigns macOS thread quality of service to QOS_CLASS_USER_INTERACTIVE via pthread_set_qos_class_self_np, ensuring that background OS energy management does not deprioritize streaming worker threads.
4. Dynamic Telemetry Linear Regression: In analyze.py, regression analysis isolates steady-state heap behavior from initial buffer pool allocations, providing accurate, drift-free slope measurements.

4. Paired results

Table 2. Multi-consumer endurance soak results across evaluated arms

Under the full 30-minute concurrent soak (Arm 3), the video pipeline sustained 60.99 unique FPS on AVFoundation and 59.98 unique FPS on shared memory simultaneously over 1,798 complete seconds. Zero complete seconds dropped below 50 FPS across either consumer. Minimum recorded per-second frame rate was 55 FPS on AVFoundation and 59 FPS on shared memory, with median delivery locked at 60 FPS. Shared memory reading achieved 107,964 successful frame transfers with zero seqlock retries and zero torn reads. E11

Figure 1. Memory telemetry of syncd across the 30-minute endurance soak under concurrent 1080p60 video and 32-channel audio load. Blue line denotes physical footprint; purple dashed line denotes resident set size (RSS). Footprint stabilizes within 2.5 minutes at 47.6 MiB and cycles periodically to 39.2 MiB as clean pages in the CMIO buffer pool are reclaimed. Net steady-state slope is -181.94 KiB/min, confirming zero memory leaks. Full-size SVG chart.

5. Product verification

Table 3. Priority 10 Qualification Criteria Verification

All five qualification criteria passed unconditionally. The 32-channel discrete audio stream transferred 2,709,941,760 individual 32-bit floating point audio samples across 265,575 read requests over 30 minutes without a single dropped packet or cursor discontinuity. Every decoded sample was a valid finite floating point number, confirming zero numerical corruption under sustained multi-consumer load. E9 E14

6. Frame selection timing

Table 4. Consumer arrival interval and audio RTT percentiles

Timing percentiles demonstrate tight coupling to the 60.0 Hz frame clock and 48 kHz audio arrival clock. Shared memory readers achieved median arrival intervals of 16.71 ms with p95 bounded at 18.15 ms and standard deviation of 1.71 ms. CoreMediaIO DAL virtual camera clients achieved median intervals of 16.63 ms with p95 bounded at 21.14 ms. Audio round-trip latency remained well below the 20 ms interactive target, with median RTT of 0.17 ms and p99 bounded at 7.64 ms. E8 E11

7. Diagnostic results

Table 5. Diagnostic findings and architectural implications

8. Decision

Retain all architectural enhancements in upstream main:

1. The non-blocking capture mutex lock in native/src/audio_capture.cpp.
2. The high-throughput socket queue and 4 MiB receive buffer in native/src/server.cpp.
3. The user-interactive thread QoS elevation in native/src/main.cpp.
4. The 32-channel discrete test fixtures in native/src/audio_native.cpp.

Priority 10 is formally qualified and closed on macOS. Next action: proceed to cross-platform endurance verification on Windows and Linux.

9. Limits

This qualification was conducted on an Apple M4 host under macOS 15.3.1. While Windows and Linux concurrency architectures achieved parity in Priorities 8 and 9 (E12, E13), 30-minute endurance soak runs on those platforms will be documented in subsequent research updates.

10. Reproducibility

To reproduce this 30-minute qualification experiment:

# 1. Build syncd with test fixtures enabled
cd /Users/alex/platform/sync
cmake --build build -j 4

# 2. Execute the 30-minute endurance soak
cd /Users/alex/sync-experiments/2026-09-22-1080p60-multi-consumer-audio-soak
node run-experiment.mjs --arm arm-3x-concurrent-multiconsumer-audio

# 3. Analyze results and generate figures
python3 analyze.py

Evidence references

1. E1. Sync 1080p60: native AVFoundation versus Chromium capture, 18 September 2026.
2. E2. Sync 1080p60: controlled sender stage separation, 18 September 2026.
3. E3. Sync 1080p60: combined audio (32-ch) and video load qualification, 18 September 2026.
4. E4. Sync 1080p60: Windows camera and WASAPI platform parity, 18 September 2026.
5. E5. Sync 1080p60: audio session recovery and dynamic permission renegotiation, 19 September 2026.
6. E6. Sync 1080p60: Windows Media Foundation virtual camera sustained delivery, 19 September 2026.
7. E7. Sync 1080p60: web-to-native frame pacing and browser capture pipeline optimization, 20 September 2026.
8. E8. Sync 1080p60: packaged electron desktop native shared memory bypass, 21 September 2026.
9. E9. Sync 1080p60: discrete multichannel audio modulation qualification, 21 September 2026.
10. E10. Sync 1080p60: windows named shared memory desktop capture bypass, 21 September 2026.
11. E11. Sync 1080p60: multi-consumer concurrent capture and zero-starvation qualification, 22 September 2026.
12. E12. Sync 1080p60: windows fscs and directshow multi-consumer concurrency qualification, 22 September 2026.
13. E13. Sync 1080p60: linux v4l2 and shared memory multi-consumer concurrency qualification, 22 September 2026.
14. E14. Sync 1080p60: multi-consumer endurance soak and resource stability qualification, 22 September 2026 (this report).