The current 1.1 release of JackTrip was crashing for me every time a client connected to it. I was able to work around this by building the latest from source code (I used the “aaron” branch).
JackTrip has some extremely useful command-line parameters that are undocumented. It’s currently best to look at the code to understand what is available.
I used the “-S ” option to run a JackTrip server instance on both my LAN and an EC2 server in the us-west-1 region. The capital S causes JackTrip to listen TCP on port 4464, automatically spawning new threads listening on 61000 UDP +1 for each client that connects to it. Note that clients need to use a corresponding “-C” (capital C) to connect.
The “-S” option is best paired with the “–hubpatch” option. I was really confused at first because it seemed to be working, but no sound was coming through. Using “–hubpatch 2” tells JackTrip to automatically create Jack connections to fan-in/out all the audio from clients.
JackTrip will automatically start the Jack daemon for you if it’s not already running, and you can use a jackdrc file located either at /etc/jackdrc or ~/.jackdrc with the command line it should use. This makes it a lot easier to start up standalone JackTrip servers with a single command. Use the “dummy” device when running Jack on a server. For example, here is what my ~/.jackdrc file looked like for one of the tests:
/usr/bin/jackd -d dummy --rate 48000 --period 128
I used two Raspberry Pi model 4’s running the latest Raspbian connected via Ethernet cables to my home LAN. One of the Pi’s had a loopback cable connecting audio input to output. On the other Pi, I used the qjackrcd utility to record WAV files to measure latency. I connected my system’s capture device to it’s left recording channel, and JackTrip’s receive device to its right recording channel. I then used Audacity to measure the latency between the signals on the left and right channels. This gives a “round trip latency” which is roughly twice the one-way latency.
All my tests used a single channel per client (“-n 1” on both server and clients). My Internet tests used a different “–bindport” for the second client, since my NAT’d traffic otherwise appeared from the server’s perspective to all be coming from the same client. My Internet testing all ran over an AT&T Fiber connection with 6-7ms round-trip ping times.
Now that I got all that out of the way, here are the results:
|Client Devices||Remote Server||Latency|
|Sabrent USB’s (128 frames/period)||LAN (<1ms ping)||42ms|
|Focusrite 2i2’s (128 frames/period)||LAN (<1ms ping)||39ms|
|Sabrent USB’s (256 frames/period)||EC2 (6-7ms ping)||79ms|
|Focusrite 2i2’s (256 frames/period)||EC2 (6-7ms ping)||92ms|
|Sabrent USB’s (512 frames/period)||EC2 (6-7ms ping)||155ms|
|Focusrite 2i2’s (512 frames/period)||EC2 (6-7ms ping)||123ms|
I was able to use a low 128 frames/period for LAN, which gave great results of roughly 20ms one-way latency. Despite the low ping times to my EC2 server, I had to raise this value for my Internet tests. At 256 frames/period I was getting occasional drop-outs logged in JackTrip but it still sounded pretty good. At 512 frames/period, I was able to almost eliminate the dropouts, but at a high latency cost.
According to the JackTrip lists, you need to use higher frames/period with USB audio but can generally lower this when using devices connected directly to the PCI bus. I’m looking forward to running some more tests when my RPi HAT’s arrive: I’ve ordered by HifiBerry’s ADC DAC+ boards and some Audio Injector boards to try out.