LATENCY TESTS - noiseorchestra/noise-audio-web GitHub Wiki
Local Area Network tests
LAN soundcard latency tests
RPi + audio interface <-> RPi + dummy soundcard
Round trip: 0 miles
Local Area Network with ethernet connection
These tests are run on a local area network and are for determining the latency which will be produced at different settings and with different hardware before the signal crosses the internet at large. Comparing the pisound and hifiberry soundcards, it looks like they each have different optimal settings (pisound performs better at 96kHz, hifiberry at 48kHz), although overall the hifiberry seems to perform better. You can also see clearly how kHz -p and settings (packets per second) effect the latency.
| client device | jacktrip settings | latency |
|---|---|---|
| RPi 4 + pisound | 48kHz -p 256 -q 2 mono | 21.334 ms |
| RPi 4 + pisound | 48kHz -p 128 -q 2 mono | 13.333 ms |
| RPi 4 + pisound | 48kHz -p 64 -q 2 mono | 6.667 ms |
| RPi 4 + pisound | 48kHz -p 32 -q 2 mono | 3.333 ms |
| RPi 4 + hifiberry DAC + ADC | 48kHz -p 256 -q 2 mono | 16.000 ms |
| RPi 4 + hifiberry DAC + ADC | 48kHz -p 128 -q 2 mono | 8.000 ms |
| RPi 4 + hifiberry DAC + ADC | 48kHz -p 64 -q 2 mono | 4.000 ms |
| RPi 4 + hifiberry DAC + ADC | 48kHz -p 32 -q 2 mono | 2.667 ms |
| RPi 4 + pisound | 96kHz -p 256 -q 2 mono | 8.000 ms |
| RPi 4 + pisound | 96kHz -p 128 -q 2 mono | 5.333 ms |
| RPi 4 + pisound | 96kHz -p 64 -q 2 mono | 3.333 ms |
| RPi 4 + pisound | 96kHz -p 32 -q 2 mono | 1.667 ms |
| RPi 4 + hifiberry DAC + ADC | 96kHz -p 256 -q 2 mono | 10.667 ms |
| RPi 4 + hifiberry DAC + ADC | 96kHz -p 128 -q 2 mono | 6.667 ms |
| RPi 4 + hifiberry DAC + ADC | 96kHz -p 64 -q 2 mono | 2.667 ms |
| RPi 4 + hifiberry DAC + ADC | 96kHz -p 32 -q 2 mono | 1.333 ms |
Stream size tests
These measurements show how much data is transfered across the network at different settings. If your upload or download bandwidth is limited (because of infrastructure or your internet service provider (ISP)) then these numbers are important to figure out what settings will work for you (see below example of poor bandwidth connection).
48kHz -p 256 mono: 937kbps
48kHz -p 128 mono: 1.099mbps
48kHz -p 64 mono: 1.422mbps
48kHz -p 32 mono: 2.066mbps
96kHz -p 256 mono: 1.717mbps
96kHz -p 128 mono: 2.189mbps
96kHz -p 64 mono: 2.836mbps
96kHz -p 32 mono: 2.976mbps
48kHz -p 256 stereo: 1.630mbps
48kHz -p 128 stereo: 1.717mbps
48kHz -p 64 stereo: 1.890mbps
48kHz -p 32 stereo: 2.234mbps
Over the Internet tests
These tests involve sending an audio signal from a client device to server which sends the same audio signal back. You can then listen to the returned audio and judge what deterioration has occurred in transport. Latency is also measured so you can know how long the round trip took. We are renting a relatively inexpensive virtual server (which is physically located in Surrey, UK) and running jacktrip in hubmode. It seems that the server isn't powerful enough to run at high kHz and very low packets per second. At a later point we'll perform peer-2-peer tests too.
London (client) <-> Surrey (server)
Round trip: 57 miles
EE ADSL Broadband with ethernet connection
Upload speed: 980kbps
Download speed: 2.32mbps
RPi 4 dummy soundcard
| jacktrip settings client | server queue | stream size | latency |
|---|---|---|---|
| 48kHz -p 256 -q 4 mono | -q 4 | 937kbps | 42.667 ms |
This was the only setting which produced good audio quality. Anything in stereo returned audio which was tuned down by a semitone and pretty doomy. Anything at -p 128 had regular glitches. This would seem to be because all higher settings require more upload bandwidth than this network can provide. This has become our benchmark for "bad ISP".
Manchester (client) <-> Surrey (server)
Round trip: 434 miles
images/manchester_surrey_manchester.png
Virgin ADSL Broadband with ethernet connection
Upload speed: 9.9mbps
Download speed: 73mbps
RPi 4 pisound soundcard
| jacktrip settings client | server queue | stream size | latency |
|---|---|---|---|
| 48kHz -p 256 -q 4 mono | -q 4 | 937kbps | 48.000 ms |
| 48kHz -p 128 -q 4 mono | -q 6 | 1.099mbps | 37.334 ms |
| 48kHz -p 64 -q 4 mono | -q 20 | 1.422mbps | 41.333 ms |
| 48kHz -p 256 -q 4 stereo | -q 4 | 1.63mbps | 58.667 ms |
| 48kHz -p 128 -q 8 stereo | -q 6 | 1.717mbps | 45.333 ms |
| 96kHz -p 256 -q 6 mono | -q 10 | 1.717mbps | 37.333 ms |
| 96kHz -p 128 -q 20 mono | -q 12 | 2.189mbps | 34.667 ms |
| 96kHz -p 256 -q 10 stereo | -q 10 | ???mbps | 45.333 ms |
| 96kHz -p 128 -q 20 stereo | -q 14 | ???mbps | 36.000 ms |
London (client) <-> Surrey (server)
Round trip: 57 miles
EE 4G Router with ethernet connection
Upload speed: ???kbps
Download speed: ???mbps
RPi 4 dummy soundcard
| jacktrip settings client | server queue | stream size | latency |
|---|---|---|---|
| 48kHz -p 256 -q 12 mono | -q 8 | 937kbps | 117.333 ms |
| 48kHz -p 128 -q 28 mono | -q 16 | 1.099mbps | 125.333 ms |
| 48kHz -p 256 -q 12 stereo | -q 8 | 1.63mbps | 122.667 ms |
| 48kHz -p 128 -q 28 stereo | -q 16 | 1.717mbps | 128.000 ms |
Ethernet cable comparison
When I first started using jacktrip I was getting some regular clicking and other strange audio defects. After replacing my ethernet cable as well as the cable connecting my router to the BT socket the signal improved greatly. It's definitely worth replacing all cables as a first step if you're experiencing problems with your connection. The images below show a ping test before and after replacing the cables. As you can see the first set with old cables show lots of erratic ping responses, each of these would be audible as an audio glitch when using jacktrip.
Old / defective ethernet cables
images/before-ping-manchester.png
