Is this page helpful?

Windows Performance and Deployment Guide#

Use the measurements on this page to validate an integration and to decide whether the Windows Audio Effects SDK matches the intended deployment. These numbers are reference measurements from one system, not guarantees for every GPU, driver, audio corpus, or application architecture.

R22 x64 Reference Measurement#

The final R22 x64 package was measured on Windows with SDK version 3.0.0.25, an NVIDIA RTX 3500 Ada Generation Laptop GPU, and the packaged 16-kHz mono sample audio. The single-effect workload used Denoiser v2 with 10-ms frames (160 samples) and processed five complete recordings per process. The representative chain used 16-kHz Denoiser followed by 16-kHz-to-48-kHz Super Resolution and processed two recordings per process. Each workload was started in a new process three times. These results measure separate process invocations; they do not represent a cold operating-system boot. The first process includes effect creation and model loading; later processes might benefit from operating-system, driver, and model caches.

Final x64 Package Controlled Benchmark#
Measurement	Denoiser v2	Denoiser + Super Resolution
Process invocations	3	3
Per-file `NvAFX_Run` averages	15	6
p50 `NvAFX_Run` time per 10-ms frame	0.374 ms	0.442 ms
p95 `NvAFX_Run` time per 10-ms frame	0.410 ms	0.479 ms
p50 processing throughput	26.74x real time	22.48x real time
p05 processing throughput (lower tail)	24.40x real time	20.90x real time
p50 / p95 system CPU utilization	46% / 68%	2% / 47%
p50 / p95 GPU utilization	11% / 68%	1% / 58%
p95 GPU memory use	215 MiB	181 MiB
First-process wall time	8.844 s	4.485 s
Repeated-process wall times	10.361 s and 10.112 s	5.832 s and 5.814 s

The release acceptance thresholds for both reference workloads are a p95 NvAFX_Run time below the 10-ms frame budget and p05 processing throughput above 1.0x real time. Throughput uses p05 because higher values are better; p05 represents the lower-performing tail. The measured x64 package passes both thresholds for both workloads. CPU utilization is system-wide Windows processor load. GPU utilization and memory are sampled from nvidia-smi. Command duration includes process startup, effect creation, model loading, all selected audio files, file I/O, and teardown; it is not frame latency.

Reproduce the x64 Measurement#

Build the packaged sample for x64 Release, acquire the Ada Denoiser and Super Resolution features, and run run_effects_demo.bat -g ada -e denoiser -isr 16k -osr 16k -ir 1.0 -ev 2 -vad 1 three times. Then run run_effects_demo.bat -g ada -e denoiser -isr 16k -osr 16k -e2 superres -isr2 16k -osr2 48k three times. Capture the NvAFX API Call Timing Summary emitted for each file and calculate p50/p95 from the per-file NvAFX_Run averages. Calculate p50/p05 from the real-time factors (audio duration divided by processing time). Report Windows system CPU load and nvidia-smi GPU utilization and memory samples while each command runs.

Open PowerShell at the extracted x64 SDK root and reproduce the process invocations described in the preceding paragraph. This block is x64-only; it contains no ARM64 commands:

$env:AFX_SDK_ROOT = (Resolve-Path .).Path
cmake -S .\samples -B .\samples\build -A x64
cmake --build .\samples\build --config Release
$helper = '.\samples\build\Release\scripts\run_effects_demo.bat'
1..3 | ForEach-Object { & $helper -g ada -e denoiser -isr 16k -osr 16k -ir 1.0 -ev 2 -vad 1; if ($LASTEXITCODE -ne 0) { throw "Denoiser run $_ failed" } }
1..3 | ForEach-Object { & $helper -g ada -e denoiser -isr 16k -osr 16k -e2 superres -isr2 16k -osr2 48k; if ($LASTEXITCODE -ne 0) { throw "Chain run $_ failed" } }

Reproduce the Measurement on NVIDIA N1X (ARM64)#

On NVIDIA N1X, open PowerShell at the extracted Windows ARM64 SDK root, build the samples for ARM64, and run the build-produced helpers without -g. Five invocations of each workload provide enough repeated samples for percentile reporting while keeping model-load and per-frame timing separate:

$env:AFX_SDK_ROOT = (Resolve-Path .).Path
cmake -S .\samples -B .\samples\build-arm64 -A ARM64
cmake --build .\samples\build-arm64 --config Release
$helper = '.\samples\build-arm64\Release\scripts\run_effects_demo.bat'
1..5 | ForEach-Object { & $helper -e denoiser -isr 16k -osr 16k -ir 1.0 -ev 2 -vad 1; if ($LASTEXITCODE -ne 0) { throw "Denoiser run $_ failed" } }
1..5 | ForEach-Object { & $helper -e denoiser -isr 16k -osr 16k -e2 superres -isr2 16k -osr2 48k; if ($LASTEXITCODE -ne 0) { throw "Chain run $_ failed" } }

Report p50/p95 frame latency, p50/p05 real-time factor, model-load time, process wall time, CPU, GPU, and memory fields. Treat the x64 values in the preceding section as x64 reference evidence, not as N1X targets. Apply the documented real-time thresholds to the N1X results.

For an application-specific release decision, repeat the procedure on every supported GPU tier with representative audio, both cold and warm application state, and every production effect or chain. Record CPU and GPU utilization alongside frame latency so that resource contention is visible. A production integration should define its own thresholds before collecting results.

Measure warm in-process operation by creating and loading an effect once, discarding an explicitly documented warm-up interval, and then processing at least 30 representative recordings through the same handle. Report p50/p95 frame latency, real-time factor, and resource utilization. Measure cold startup separately in a new process after a documented reboot or cache-reset procedure, and report effect creation and model-load time separately from NvAFX_Run. For concurrency testing, repeat at each supported production stream count and fail the release if the predeclared frame or throughput threshold is missed.

Deployment and Integration Fit#

The following comparison is a deployment-selection guide. It makes no unmeasured claim about perceptual audio quality and does not substitute for a listening evaluation on the application’s own corpus.

Decision Area	Windows Audio Effects SDK R22	Evaluate Another Deployment When
Effect breadth	Denoiser v1/v2, dereverb, combined dereverb and denoiser, Super Resolution, Speaker Focus, and Studio Voice HQ/LL; documented compatible chains are also available.	The product requires transcription, codecs, acoustic echo cancellation, or another capability outside this set.
Hardware and OS	Local Windows 10/11 x64 with a supported NVIDIA Tensor Core GPU; NVIDIA N1X uses the Windows ARM64 package.	CPU-only execution, a non-NVIDIA GPU, mobile, or browser-only execution is a hard requirement.
Integration surface	Native C API, import library and DLLs, dynamic loading, CMake consumer sample, and batch helpers.	A managed-language-only or hosted HTTP API is required without a native bridge.
Feature acquisition	Core SDK plus independently downloaded NGC feature payloads selected by GPU architecture and sample rate.	Deployment must be a single offline artifact with no authenticated feature acquisition step.
Deployment target	Client-side local Windows integration; the separate Linux SDK targets server deployments.	The primary target is a server or cloud service, where the Linux SDK or a service architecture should be evaluated.
Performance evidence	Frame-level timing is available from the sample and can be measured against the application’s real-time frame budget.	A decision requires results for a GPU, concurrency level, or audio corpus that has not been benchmarked.

Market Alternatives and Differentiation#

Use the following matrix for architectural selection. It compares documented product surfaces, not perceptual quality. Product capabilities and licensing can change, so verify the linked primary documentation during procurement.

Documented Integration Alternatives#
Option	Documented Execution Surface	Documented Audio Scope	Best Fit to Evaluate
Windows Audio Effects SDK R22	Native C API on Windows x64 with a supported NVIDIA Tensor Core GPU; Windows ARM64 on NVIDIA N1X.	Denoiser, dereverb, combined dereverb and denoiser, Super Resolution, Speaker Focus, Studio Voice HQ/LL, and compatible chains.	A local Windows product that can use RTX acceleration and needs several enhancement effects through one API.
Krisp RTC SDK	CPU execution across documented server, desktop, mobile, and browser targets.	Its RTC SDK documents background-voice cancellation and noise cancellation models.	CPU-only, mobile, browser, or broad cross-platform RTC deployment.
WebRTC Audio Processing Module	Native WebRTC pipeline component that can also be used standalone.	Echo cancellation, noise suppression, and automatic gain control.	An RTC stack that needs WebRTC-native capture processing, AEC, or AGC.
RNNoise	Open-source C noise-suppression library with a command-line example.	Suppression of recurrent neural-network noise; the example documents 48-kHz mono raw PCM.	An open-source denoising baseline or a narrowly scoped C integration.

The R22-specific differentiation is effect breadth in a single Windows-native API plus measured RTX frame-latency headroom for the two reference workloads discussed earlier. This statement does not claim superior perceptual quality. Before a competitive decision, run every candidate on the same licensed audio corpus, hardware class, frame size, concurrency, and warm-up policy. Predeclare the latency, throughput, CPU/GPU, memory, objective-quality, and listening-test criteria; retain raw outputs and report both passing and failing samples.

Release Checklist#

Before shipping an integration:

Verify the exact SDK and feature versions and retain the feature-download receipt.
Build a clean consumer against only the packaged public headers and libraries.
Exercise every selected effect, supported chain, and production intensity value, including malformed and out-of-range inputs.
Validate output sample rate, channels, duration, finite samples, and non-silent output; use a listening test for perceptual quality.
Measure cold and warm frame latency, p50/p95, real-time factor, and CPU/GPU utilization on each supported hardware tier.
Confirm that logs and published reports do not contain credentials.