Performance reports

Sync multichannel audio input: capture path and qualification

14 September 2026 · Research report · Revision 2 · Native audio input

Sync implements native audio capture through RtAudio and transfers interleaved float32 samples to Noisedeck through its authenticated localhost connection. The browser adapter supplies discrete channels to an AudioWorklet and the existing band and raw-signal analysis. The implementation is included in native preview 0.2.68 and SDK 0.3.0. E1 E2

The retained qualification consists of two short Linux native probes, a separate 30-second Linux-to-Chromium integration run, synthetic integration tests, and cross-platform build and package checks. The browser run retained channel identity but reported dropped frames. Physical AudioFuse capture, Windows WASAPI capture, signed installed macOS audio permission, and sustained simultaneous audio/video operation remain unqualified. This editorial revision contains no new capture measurements. E1 E2

1. Scope and source revisions

The requirement is 1–32 independently selectable input channels per native source, with stable channel order during capture and signed samples available to the existing raw-control calculation. The application must expose the opened source's actual channel count. It must not synthesize additional channels when a driver exposes fewer inputs. Audio output, recording, arbitrary channel remapping, native video input, network audio distribution, and sample-accurate audio/video synchronization are outside this implementation. E3 E4

Table 1. Source and release identifiers

Companion and SDK version numbers are independent. A client must check that an audio provider with receive direction is selected and available. A product version alone is insufficient for capability detection. E2 E3

2. Browser capture boundaries

The reported interface exposed many native input ports while its Chromium capture stream exposed two. Source inspection identified restrictions at device capture and at a later MediaStream-to-Web-Audio conversion. The two-channel result depends on the selected implementation path. It is not a general limit on the number of channels in a Web Audio graph. Source checks date from 13 September 2026; available source receipts were refreshed on 14 September. E5

Table 2. Browser boundaries examined

Noisedeck already requests an ideal count of 32 and disables echo cancellation, noise suppression, and automatic gain control. Its TrackProcessor bridge addresses the later conversion boundary. Neither configuration can recover inputs discarded during capture. The initial synthetic MediaStream destination experiment encountered a separate eight-channel fixture limit; it did not establish the limit of an independently supplied worklet. Capture constraints E5 E6

3. Alternative designs

Table 3 records design assessments for independent audio and signed control inputs. The alternatives were not subjected to a common performance comparison. Their disposition follows the capture boundary, implementation scope, and deployment requirements. E5

Table 3. Capture and transport alternatives

4. Native capture and ownership

RtAudio 6.0.1 is pinned to source revision b4f04903312e0e0efffbe77655172e0f060dc085 with an archive checksum. Sync implements device enumeration, capture lifetime, buffering, protocol encoding, and browser integration around that dependency. The package notices include its license. Build definition Pinned dependency

The selected backend is CoreAudio on macOS, WASAPI on Windows, and ALSA or JACK on Linux. The initial Windows build does not enable ASIO. The Linux release includes the JACK path; PipeWire supplies JACK compatibility through pw-jack. The installed service must start through that wrapper to use it. Installing the compatibility package alone does not modify a running service. E3 E5

Opening a source selects the first min(inputChannels, 32) channels at the device's reported current or preferred sample rate. Physical inputs above 32 cannot be selected, and arbitrary channel maps are not implemented. Source identifiers derive from backend and device name. Duplicate names within one backend are omitted because the current API does not provide a persistent hardware identifier that distinguishes them. E3

Capture belongs to the authenticated connection that opened it. Foreign reads and closes are rejected. Device open and capture work are separated from the control-loop work; pending cleanup retains the connection until completion. The client pulls bounded packets rather than receiving an unbounded pushed stream. Slow-open cleanup and ownership checks have separate fixture coverage. E3 E6

The protocol-v1 capability catalog has four entries for compatibility with existing video clients. Normal platform defaults leave room for audio. An advanced command-line selection of all four video providers disables audio and emits a diagnostic. Provider registration

5. Transport format and buffering

Audio uses authenticated listAudioSources, openAudioSource, readAudioSource, and closeAudioSource control requests. Discovery supplies identifiers, names, channel counts, and sample rates. Open returns the actual format. Reads return binary sample packets; errors remain bounded JSON responses. The SDK gives open a 60-second deadline to accommodate operating-system permission. Ordinary reads retain the configured control deadline. E4

Table 4. Audio packet layout

Numeric fields are little-endian. The maximum packet size is 32 + 480 × 32 × 4 = 61,472 bytes, below the server's 64 KiB queued-write limit with WebSocket framing. The SDK represents uint64 cursors as BigInt and rejects invalid lengths, unsupported formats, and nonfinite incoming samples. E4

The browser converts the interleaved samples into transferable channel planes. The worklet has a 4,096-frame ring and a 512-frame prefill. At 48 kHz, those counts correspond to 85.33 ms of capacity and 10.67 ms of prefill. Neither value is a measured end-to-end latency. The AudioContext rate must match the received rate; this path has no resampler or shared audio/video clock. E5

At 32 channels and 48 kHz, the sample payload is 32 × 48,000 × 4 = 6,144,000 bytes/s, excluding transport overhead. A detected native cursor gap or change in the native drop counter resets worklet state. A browser worklet underrun holds the last sample until data can resume. These behaviors differ and must be measured separately. E4 E5

6. Browser integration and permissions

Noisedeck's audio automation provides Connect Sync audio and lists native source names with a Sync suffix. Native identifiers use the sync-audio: prefix. Compiled audio requirements determine which inputs are opened, and removal of the final consumer closes the source. Native selection bypasses getUserMedia. The browser output is connected through zero gain; this input controls visual parameters rather than providing speaker playback. E5 E6

The channel selector uses the actual opened count. Existing low, mid, high, volume, and raw calculations remain in use. Raw zero maps to the midpoint between the visual parameter's minimum and maximum. Preservation of signed samples does not establish that a physical interface is DC-coupled or compatible with a particular control voltage. Audio response reference

Saved video-origin tokens do not automatically grant audio access. Native audio discovery and capture require explicit successful pairing during the current daemon lifetime. Restarting Sync requires fresh audio approval. Operating-system microphone permission is separate from origin pairing. The macOS audio helper requests that permission on open. Audio authorization macOS permission

Audio and video share the companion and local pairing infrastructure, but use different data paths. Video carries browser frames to native receivers; audio carries native samples into the browser. Audio frame cursors are not timestamps in a shared video clock domain. E3 E4

7. Measurement method

The native probe opens a separate JACK software source that generates 32 distinguishable constant signed signals. For channel n, numbered 1–32, the expected value is (−1)^(n+1) × n / 64. Odd channels are positive and even channels are negative. This pattern detects channel permutation, duplication, loss, sign changes, and altered sample values along the tested route. It does not measure a physical converter's frequency response, DC behavior, crosstalk, or noise. Source generator E1

One audio frame contains one sample from every input channel. The native probes run for a configured 2,000 ms, report received frames, exclude 1,024 startup frames from pattern validation, and count incorrect samples, cursor discontinuities, and native ring drops. The two final probes ran on Ubuntu 24.04 x86_64, separately through JACK and PipeWire's JACK compatibility path. E1 E2

The separate browser acceptance run used an Ubuntu 24.04 ARM64 container on a macOS host and Chromium 148.0.7778.96. Its route was JACK source → production RtAudio capture → Sync daemon → SDK 0.3.0 → Noisedeck worklet → channel selection and raw analysis. It checked all 32 selector choices and sampled the signed raw values once per second during a configured 30-second interval. All received packets subject to pattern validation were checked across the channels. The aggregate records incorrect packets rather than an incorrect-sample total. E1 E6

The browser test used isolated test authentication; installed approval dialogs were not exercised. Native video was inactive. The container relay was a test arrangement, with the browser and daemon on separate sides of the host/container boundary. A normal installation runs both on one host. These conditions constrain the interpretation of the results. E1 E5 E6

8. Results

Table 5. Retained 32-channel, 48 kHz captures

Both native probes reported zero cursor discontinuities. The browser receipt contains 4,330 packets and no separate aggregate discontinuity count. Every test excludes 1,024 startup frames from its pattern validation. The frame totals include the test's capture and setup timing; they are not used here to derive a precise throughput estimate from the configured duration. E1

The browser run reported 1,024 native ring drops, equivalent to 1,024 / 48,000 = 0.02133 s of missing audio in total. This quantity is not transport latency. Zero mismatched packets establishes consistency of the validated received data; it does not establish continuity across the missing frames. The once-per-second raw checks also do not form a continuous trace of worklet output. E1

Figure 1. Retained signed values by input channel in the browser acceptance record. The plotted observations match the source pattern defined in section 7. The figure is not a time series. Full-size figure. E1

The earlier 13 September run validated 1,479,072 frames, with zero mismatched packets and 1,088 dropped frames. It is a separate historical experiment; its interval is not combined with the current run to imply a longer test. E7

The first container-relay attempt delivered 130,560 frames over roughly 12 seconds and reported 434,144 drops. It used 8 KiB transfer chunks with Nagle enabled, and its worklet repeatedly reset before reaching the expected raw values. A repeat using 64 KiB chunks and TCP_NODELAY on both relay sockets passed. Both settings changed together, so their individual causal contributions were not isolated. Sync already enabled TCP_NODELAY on its accepted sockets; the correction affected the test relay. E7 Socket configuration

9. Platform and release qualification

The exact native source passed all 11 jobs in the cross-platform CI matrix. The separate Windows camera workflow also passed. These workflows establish their recorded build, packaging, lifecycle, and video outcomes; they do not turn an absent audio endpoint or an untested physical interface into a capture result. E2

Table 6. Platform evidence and missing qualification

Local automated checks retained 153 SDK/package passes, 247 JavaScript unit passes, 22 macOS native test groups, and 30 macOS real-loopback passes. Noisedeck feature source passed 902 Node tests with one existing skip and 10 browser tests. These counts describe separate software suites; they are not physical-device qualification counts. E2 E6

Seven Noisedeck browser cases use the standalone synthetic server: four channel-count cases at 1, 2, 8, and 32; source independence; ownership and slow-open cleanup; and a missing source without microphone fallback. Three additional cases test video/audio credential propagation, fresh audio consent with video recovery, and stale consent failure after credential replacement. These ten cases do not constitute a new production-driver or combined-load capture. E6

Native preview 0.2.68 and SDK 0.3.0 were published from the source in Table 1. Retained public byte checks matched expected installer and SDK sizes and SHA-256 hashes. Noisedeck preview deployment, promotion, production deployment, and health checks passed. Physical audio and combined-load claims remain subject to Table 6. E2

10. Limitations

• The wide-input tests use software-generated signals. They do not qualify an AudioFuse or another physical interface, ADC, input profile, or driver version.
• The two native probes and separate browser run are short tests. They do not establish long-session reliability or uninterrupted delivery. The browser drop count is nonzero.
• The raw observation cadence is one second. No continuous per-channel worklet-output trace, CPU profile, memory-growth measurement, or calibrated end-to-end latency result is retained.
• The container relay introduces an additional transport arrangement. Its failure and correction cannot be generalized into a measured performance result for a normal installed companion.
• The browser run used isolated authentication. Installed permission behavior remains distinct from protocol and credential tests.
• The initial implementation uses the first 32 reported channels, has no arbitrary channel map or resampler, and has no shared sample-accurate audio/video clock.
• WASAPI capture, signed installed macOS audio permission, physical AudioFuse input, and sustained combined audio/video use remain pending.

These limits follow the retained experiment conditions and implemented bounds. No additional hardware or performance qualification was conducted for this document revision. E1 E2 E3 E6

11. Qualification plan

The next experiments must retain the same distinction between channel correctness, continuity, installed permission, and video delivery. Table 7 defines the required observations. These are planned actions, not completed results.

Table 7. Next qualification actions

Video I/O remains a parallel qualification effort with its own delivery criteria. Relevant records are the bounded camera acquisition report, the video research plan, and the 0.2.68 video release measurements. None supplies simultaneous native-audio evidence.

12. Reproducibility

The public normalized measurements identify native probe results, browser environment, channel values, frame counts, and qualification limits. The source receipts reference the qualification record at an immutable repository revision. Both JSON files are byte-identical to the first publication. This revision replaces the exposition and layout and removes the figure's headline treatment. E1 E5

Reproduction uses the isolated JACK source, the production daemon, and the native-audio browser acceptance script. The source generator and test assertions are linked below. The full instructions specify build commands, separate foreground processes, test-origin authentication, expected source name, and container relay settings when needed. Test authentication is confined to that isolated setup. Reproduction procedure Acceptance script Signal source

Generated artifacts, original receipts, the preceding publication, and verification outputs remain in the experiment archive outside Git. The served bundle retains its existing address, and its checksum manifest identifies this revision. User setup and recovery procedures remain on the audio guide and troubleshooting page.

Evidence references

1. E1. Normalized measurements, nativeProbes, browserAcceptance, and qualification. Frame counts, sample pattern, environment, duration settings, and retained limits. Original record: audio-qualification.json.
2. E2. Qualification and release record, ciQualification, localChecks, and releasePreparation. Cross-platform source CI; Windows camera and audio inventory; Installer publication; SDK 0.3.0.
3. E3. Native enumeration and capture; Capture contract; Ownership, control loop, and authorization; Capability registration. Exact native source from Table 1.
4. E4. PCM encoder; Control protocol; SDK decoder and operations; Wire-format tests; Video protocol.
5. E5. Native audio research and implementation notes. Browser-boundary review, alternatives, buffering, platform setup, and scope. Retained source references and content digests.
6. E6. Standalone synthetic fixture; Production-driver browser assertions; Loopback and consent checks; Retained Noisedeck case list and test outcomes.
7. E7. Earlier browser acceptance; Failed container-relay diagnostic. Separate historical measurements, 13 September 2026.