I've seen numerous claims about Krisp's "near-zero" latency, but concrete, reproducible measurements are surprisingly scarce. As someone who benchmarks audio processing pipelines for real-time applications, I find this lack of data problematic. Vendor marketing often cites "under 20ms" or similar, but the methodology is rarely disclosed.
To establish a baseline, I ran a controlled test using a local loopback setup on a Windows 11 system (i7-12700H, 32GB RAM). The goal was to isolate the processing delay added by Krisp's noise cancellation alone, excluding network latency. I used a virtual audio cable (VB-Cable) to route a generated tone from a Python script, through Krisp as the input device, and back into a recording script. The time difference between the sent signal and the received, processed signal constitutes the added latency.
Here are the results from 1000 sequential samples, with Krisp set to "Voice" mode and noise cancellation enabled:
```
Test Configuration:
- Sample Rate: 48 kHz
- Buffer Size: 256 samples
- Krisp Version: 2.26.0
Measured Latency Statistics (ms):
- Mean: 18.7
- Median: 18.2
- Std Dev: 2.1
- 95th Percentile: 21.8
- Minimum: 16.4
- Maximum: 28.1
```
Key findings:
* The **typical added latency is between 17-22ms**. This aligns with the "under 20ms" claim, but shows a consistent overhead.
* The latency is not perfectly stable; buffer variations and system load can cause spikes near 30ms.
* This adds directly to your existing audio pipeline latency (e.g., from your microphone, audio interface, and communication software like Zoom or Discord).
For most voice calls, this is acceptable. However, for professional audio work, real-time musical collaboration, or competitive gaming comms where total latency is critical, this ~20ms must be factored into your total budget. I would be interested if others have conducted similar tests, especially on macOS or with different Krisp modes (like "Voice & Noise" or "Custom").
Benchmarks > marketing.
BenchMark
Your methodology is sound for isolating algorithmic latency. However, I'd challenge the buffer size as a confounding variable. With a 256-sample buffer at 48 kHz, you're introducing 5.33ms of inherent latency before Krisp even processes a frame. Your measured mean of 18.7ms likely includes this buffer's queuing delay and the driver's processing overhead.
The more interesting figure is the variance, which your std dev of 2.1ms shows. That's where you see the real-world jitter impact. For a true end-to-end real-time pipeline like VoIP, you'd need to add at least one more buffer stage on the output, potentially doubling that median figure.
Have you considered repeating the test with a much smaller buffer, say 64 or 128 samples, to see if the Krisp processing time itself remains constant or if the driver/model becomes unstable?
throughput is truth