[rdtennent]

My experience with Jamulus might be instructive. Members of our group live in the same city (Kingston, Ontario) but use two ISPs. Packets between users on the same ISP were fine but packets from one ISP to the other were being routed via Toronto and then Chicago and ultimately back to Kingston. It's not the distance travelled that's the problem (speed of light), it's the latency introduced by each intermediate node.

Solved the problem by setting up a Jamulus server on AWS in Montreal. Both ISPs provide low-latency connections to Montreal, much better than one mile across town!

Of course each participant has to use ethernet rather than WiFi and has to use a low-latency audio device, not a laptop sound card.

[__turbobrew__]

Something similar was happening in Calgary where multiple ISPs in Calgary peered through Seattle and Toronto. Luckily YYCIX was formed and it appears that things are much better now: https://yycix.ca/talks/cuug-2013-06-18/mgp00001.html

[porcc]

How can you detect these node transfers? I run into similar problems often with WebRTC and I have found it troublesome to diagnose

[rdtennent]

traceroute

[nemetroid]

Had the same experience in Sweden. Between certain pairs of ISPs, all traffic was routed via one of the capital cities (Stockholm, Copenhagen, Oslo), adding 10-20 ms and jitter. Solved it by setting up a VPS at a provider with good connections to all ISPs involved.

[weepy]

The issue with Jamulus is that it requires a central server - which means it needs to be close to everywhere . It also needs double buffering and double compression. P2P is the way forward here IMHO.

[rdtennent]

"requires a central server" is misleading. You can set up a server wherever; there's no central server. Except for the multiple-ISP issue I discussed, there's no reason access to a server is more latency than access between the "clients". The advantage of the server/client model is that the clients can be very lightweight: I personally use a Raspberry Pi 3 with an ultra-low latency DAC/ADC hat. Works fine. All the real computation is done on the server.

[weepy]

Well you do need to find a server midway between all the users, which is a hassle of course. I don't personally like the model either becuase it needs to decompress, mix and recomopress all the streams on the server and also needs an extra jitter buffer. The only clear benefit to it AFAIK is that it scales better for larger groups O(N) rather than O(N2)

[rdtennent]

"need to find a server midway between all the users" Nonsense. Did you read my post? The server is in Montreal; all the clients are 200 miles west of Montreal in Kingston. Physical distance isn't important. What is important is ping time. When one tries to connect in Jamulus, dozens of public servers are suggested with their ping times listed. If none are suitable or one wants a private server, one can set up a server anywhere that provides good ping times to all the intended clients. In the multiple-ISP scenario I had to deal with, a server "midway between all the users" would have been useless, as would any kind of server-less topology.

"The only clear benefit to it..."? As I suggested, a significant benefit of the Jamulus model is that any of the clients can be "thin"; most of the computation is done on the server. You may be able to improve on this but disparaging it with silly criticisms isn't going to help you; there are thousands maybe millions of satisfied Jamulus users around the world.

[weepy]

P2P doesn't require any computation on any server - it's essentially serverless. It doesn't make much sense to me at least to need to compress everything twice and have multiple buffers AND have to manage a server.

[rdtennent]

Well if any of the O(N^2) connections has unacceptable latency, you'd understand why a server is sensible. Reducing computation won't improve latency in the connections. One has no flexibility with clients but a server can be located wherever good connections are available.

[rdtennent]

> P2P is the way forward here IMHO.

But if any of the O(N^2) P2P links has unacceptable latency, eliminating the server would be counter-productive because the client-to-server connection may have less latency if the server is located appropriately.

[weepy]

Maybe I'm missing something but A->B is likely to be faster than A->S->B ?