When you experience it for yourself, it’s easy to understand how much of a difference JackTrip makes at reducing latency, not to mention offering way better audio quality. We thought it would be fun to try translating this into numbers, by generating a few objective measurements to illustrate the differences.
The Results
| Product | One-way Latency | Details |
|---|---|---|
| JackTrip | 25 ms* | 64 Buffer Size, Loss Concealment |
| JackTrip | 28 ms | 64 Buffer Size, Minimal Latency |
| JackTrip | 140 ms | Chrome Web Browser |
| Zoom | 66 ms | Live Performance Audio |
| Zoom | 155 ms | Original Sound Audio |
| Meets | 160 ms | Chrome Web Browser |
*updated for the latest 2.2 results (previously 33 ms)
The Methodology
Our goal was to measure the entire “mouth-to-ear” latency, including any network time, audio conversion time, buffering, etc. This is a bit harder than you may think. Most software will only tell you the network tramission time, or your audio interface buffer time.
For these tests, we used two people located at their homes in Palo Alto, California (“Mr. X”) and Portland, Oregon (“Mr. Y”). This represents a distance of about 560 miles, if you could travel directly. For the physics geeks among us, it only takes light about 3 milliseconds to travel this distance. The differences represent inefficiencies in audio hardware, software, and the Internet, all of which will improve with time.
To control variability in network quality, both had their computers connected via Ethernet cable to their routers (no WiFi), and both use residential Fiber Internet connections (Mr. X with AT&T Fiber, Mr. Y with CenturyLink).
Mr. X used a Windows 11 computer with a Universal Audio Volt 476, and Mr. Y used a Mac Studio running OSX 13.4.1 with a Focusrite 18i20. To come up with the one-way results, we measured the full round-trip times and divided by 2.
Mr. X used an analog patch cable to connect their Line 2 output to their Input 2 (right channel). This caused the analog signal generated by Mr. Y to be immediately re-digitized and transmitted back to him.
Mr. Y generated an audio signal by snapping his fingers. He used both Logic and Audacity to measure and confirm results. The signal he generated was recorded to channel 1 and the return signal was looped back into a 2nd recording channel via another analog patch cable. The difference in time for the two attacks was used to measure the round-trip time.
JackTrip Measurements
JackTrip measurements were created using the Desktop App version 2.0.2 with the same buffer size and strategy on the studio server and both desktop clients. Other than changing these for the different test cases, the default settings were used. The “No Effects” soundscape was used with Studio Echo set to zero to prevent any sound processing from impacting the results.
The web browser measurement were taken with Mr. X using Edge and Mr. Y using Chrome web browsers. Both disabled Echo Cancellation before joining the studio.
Zoom Measurements
Zoom measurements were generated with both clients using the same Audio settings and disabling echo cancellation. Measurements were made after ensuring that both participants had either “Original Sound” or “Live Performance” audio enabled.
Google Meets Measurements
Google Meets measurements were generated with both clients disabling echo cancellation. Even when this is disabled, Meets seems to detect echos and automatically start filtering them. We observed that this seems to only kick in after someone generates their first echo, so we were still able to take measurements by leaving and rejoining the room.