It could be still on your end. Do you know how to run a traceroute? Unfortunately, my ISP is Verizon FIOS, who somehow broke the functionality with Windows. So, I had to revert my Linux system. Here's what the output looks like:
user@my_system:~$ traceroute 45.79.61.39
traceroute to 45.79.61.39 (45.79.61.39), 64 hops max
1 192.168.0.1 0.197ms 0.126ms 0.095ms
2 * * *
3 100.41.21.204 3.540ms 4.810ms 4.889ms
4 140.222.237.227 9.855ms 9.879ms 9.857ms
5 63.65.164.121 9.920ms 12.215ms 9.787ms
6 62.115.124.225 12.383ms 12.311ms 12.437ms
7 62.115.125.128 24.800ms 24.879ms 24.591ms
8 62.115.120.113 40.184ms 39.743ms 39.844ms
9 62.115.172.135 42.289ms 42.422ms 39.866ms
10 45.79.12.5 42.265ms 39.880ms 42.367ms
11 45.79.61.39 42.287ms 42.413ms 42.153ms
On Windows, the command would look like this:
C:\WINDOWS\system32>tracert 45.79.61.39
What it reveals are the number of hops you have to traverse between endpoints and a how long it took to transfer data the data packets. In this case, it's the address of the JamKazam server.
The audio between musicians in a session appears to be set up as peer-to-peer UDP streams. This means the audio is packetized and sent without any acknowledgement it arrived intact. So, the real numbers for the latency will be smaller, but will still depend on the route between you and the others in your session. For those who are local, latency would still be a matter of how many hops it takes when traversing the 'net.
Here's an article on traceroute:
5 Ways to Traceroute - wikiHow
You can also use ping:
C:\WINDOWS\system32>ping jamkazam.com
Pinging jamkazam.com [45.79.61.39] with 32 bytes of data:
Reply from 45.79.61.39: bytes=32 time=41ms TTL=56
Reply from 45.79.61.39: bytes=32 time=43ms TTL=56
Reply from 45.79.61.39: bytes=32 time=41ms TTL=56
Reply from 45.79.61.39: bytes=32 time=41ms TTL=56
Ping statistics for 45.79.61.39:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 41ms, Maximum = 43ms, Average = 41ms
What you need to see is total latency for individual participants in the JamKazam popup panel when in a session. I assume you've discovered how to do this. Ideally, it should be below 30ms, but it's still workable when above it. Here's what you'll see when it's reasonably good. Internet latency for the participant is shown as 15.5 ms.
View attachment 3841751