This is a set of posts collated from a thread on the old forum originally titled “UK Community Jamulus server”. The thread was originally about an experimental server I set up in the UK to try to use for online jamming:
Note that the server is no longer operational.
The foliowng posts will pick out some interesting parts of the subsequent conversation.
EDIT: I’m not sure why the quoting is sometimes breaking in these posts, but I will worry about getting the content across and tidy up the formatting later.
[quote=“glpguitar”]Rossco and I gave it a go with Majik offering technical support.
…
Unfortunately we didn’t manage to get an acceptable latency no matter what settings we adjusted. Only when turning off direct monitoring, we realised how noticable latency is even for hearing yourself.
Our conclusion is that this could serve as a great open mic setting but we (with our limited knowledge, will need to wait for Majik to return to the UK) don’t see a real time jam session happening yet. So once the virus situation is gone, we suggest to have a few JG meet-ups all over the world!
[/quote]
[quote=“Rossco01”]Both GLP and myself lowered the settings on the Jitter side of things as they were constantly going green/red and giving us a lot of drop out…unfortunately that means more delay and really was unplayable together. So not sure this is a go with our current connection
Not sure I’d want to use this for open mic either as the fun bit is both hearing and seeing people play. I reckon a better approach to that would be to setup a FB group e.g. JG Open Mic Night, and then arrange suitable time so people can join, we draw up an order then people simply go FB live to play…would probably work a lot better. Might also be an “easier” route for people to play “live” for the first time.[/quote]
[quote=“Rossco01”]Did a little bit more playing with this over lunch. So I initially tried it on Majik server and it was a little betters… ping was down around 18-22 and there was less - but still some - delay…probably still a bit challenging to play with.
I also then took a look at what the public servers were like. Quite a few run around 12-14 ping rate so I joined one of those (quite a lot are empty) and that little drop in ping time makes a big difference. Clearly if you get this setup it must work well as a lot of the servers are Band servers which are used for rehearsing and they just leave them up all the time free to use if they aren’t using them.
I also wanted to explore whether my interface played a part (Focusrite 2i2 1st Gen). I tried to lower sampling rate but ASIO interface wasn’t having any of it. I do GT1 which has an interface but not sure it allows me to get output through the headphones. (it does says its 1input and 1output) so need to play with that a bit more.
For people who want to play with this you don’t need someone to jam with…if you install the software and follow instructions…turn direct monitoring off so you ONLY hear whats coming back from the Jamulus server and you’ll see how it works.
I’m going to dig in a bit more to the “ideal” Jamulus setup see if we’re missing anything[/quote]
[quote=“close2u”]Technical question …
I have retained one private guitar student whom I teach online via Zoom.
It is full of latency of course so direct play together is impossible.
Would this work as a connection for audio during lessons if we had another means of seeing other other too running alongside?[/quote]
[quote]Yes, it should work, as long as you aren’t connecting your audio to/from the video feed as well as Jamulus. One way to do this would be for both of you to mute the audio on the video call.
The video will be delayed so you will have the equivalent of “lip sync” issues so you should take your cues for jamming from the audio.
From what I have seen from observing other people’s jam sessions, the more successful ones seem to either have a drummer or a drum machine, so if you can pipe the audio from a metronome or drum sequencer app into Jamulus, that could be beneficial[/quote]
[quote=“Majik”] If you set up the port forwarding on your router, you can run your PC as your own server.
I suspect the different latency is down to geography and network routing differences.
Feel free to set up your own server on your PC and register it to my “central server” if you want. This will probably give the lowest latency of all.
Of course, you could also do that with the default central server but, in my experience, that is mostly full so registering to it is usually not possible.[/quote]
[quote=“Majik”]Delay (or “latency”, same thing) is cumulative. Every step of the signal path between your guitar and your ears will add latency. For online jamming, typically the latency is caused by:
The latency of your audio interface into the PC.
The latency of the PC in processing the audio (things like buffering) and sending it to the network
The latency of your Internet connection (which is not necessarily directly related to Internet “speed”, but is often more due to downstream routing or congestion)
The latency of the Internet connection between your ISP and the server’s ISP
The latency of the server’s Internet connection
The latency of the server receiving and mixing the audio
The latency of the server sending the mixed audio streams back out
The latency of your Internet connection receiving the audio stream
The latency of your PC in processing the received audio
The latency of your PC in sending to the audio interface.
This is the “round-trip” latency as measured by Jamulus.
Obviously, many of those things will be out of your control, such as most of the Internet latencies. But things you can do are to minimize the latency on your end. Typically this means using a low-latency audio interface with tuned drivers (proper ASIO, low buffer sizes, etc.), making sure your PC is performing well, and making sure your Internet is functioning properly and that you aren’t, for instance, streaming movies or downloading large files whilst you are trying to use Jamulus. Avoid using Wifi as that will add latency too.
[quote=“alexbuckland”]another major factor in latency is the location and quality of server you connect to.
melomax.live offer free sessions on servers tuned specifically for Jamulus speed optimisation.[/quote]
[quote=“Majik”]
That is true. And it’s the reason I stated this was specifically for UK users as the server was based in the UK, in the South of England to be specific, just like the Melomax UK server.
And it’s not so much the server itself, but the characteristics of the peering of the ISPs they use, although a dedicated server will generally give better results than a VM or container-based system.
I think the Melomax solution could be good for those interested. So far, at least in the UK, there doesn’t seem to have been a lot of interest in this. Based on some of the forum discussions around the Zoom/Streamyard Open Mic sessions, I think a lot of people are put off by the technical requirements and set up for these sorts of things.
I think Jamulus is even more of an unknown to most than Zoom, especially as it’s primarily for collaboration, where Zoom (and others) are only suitable for one-way performance type situations; not only do you have the technical requirements, but you also have to deal with the musical collaboration and communication aspects as well. That can be daunting for a beginner at a real-world jam-session, but these challenges in an online jam setting are, in many ways, increased. And with the best server/Internet connection in the world, there is still a bit of latency.
Ultimately, I get the impression there is no thirst for this, at least in this forum.
P.S. I note that you are one of the people behind Melomax.[/quote]
[quote=“tobyjenner”]Yes this seemed to die a death but I was surprised given covid restrictions etc. I really did not look into it, being in France but this last post triggered a thought.
Ok I’m not sure exactly where the Jamulus server is located but from my location to Bristol its 210 miles as the crow flies. Bristol to Hartlepool is 230 miles. Would restrictions and or latency for me, be down to the need for different geographical networks to be traversed, opposed to the “cable length”.
If the initiative had taken off and I could have joined with minimal latency, I would certainly looking for a jam buddy back in the UK. But such is life.
Thanks for all your efforts all the same. Could have been good.[/quote]
[quote=“Majik”]It’s located in the Thames Valley, not far from London, connected to a particularly good ISP. It’s a VM on a server I own, but the server isn’t particularly heavily loaded and the latency to the ISP is quite low.
I previously tried cloud-based services (GCloud and AWS) but, although they are, in theory, more centrally (with respect to “The Internet”) located in London Data Centres, I found the ping times I was getting (at least from Singapore when I set this up) were actually higher.
As you say, it’s more down to “cable length” than geographic distance, although the geographic distance gives you the absolute minimum that is physically possible.[/quote]
The latency you will get end-to-end will depend on the latency of any intermediate equipment (primarily routers) and the distance travelled. The absolute constraint is the speed of light in fibre, which is around 200,000km per second. As an aside this is the speed of light in a vaccum, 3x108 m/s divided by the refractive index of fibre, approximately 1.5)
So with your 321km crow-files distance, if you could have a dedicated fibre-optical directly from your house to Bristol (in a straight line, with no slack) the one-way latency in the fibre would be around 1.6ms, plus the latency of the router hardware you install on the ends (let’s say this is 1ms at each end for a decent router) giving you a round-trip latency of a little over 7 ms.
Now in practice, your Internet connection will go to a local street cabinet, to a local exchange, back to an ISP who may be based in a local city, which may then go back to Paris to a peering point, then it will cross the peering point to a transit provider, who may have fibre connections to London via a submarine cable, connected to cable stations on the coast of France and the UK (although a fibre-network company I used to work for had their fibre going through the channel tunnel). Then this will be connected up to London by one or more networks, which will connect to the ISP hosting the server.
Note that a lot of these national fibre networks follow common routes, which are NOT direct. It’s often based on where they can get the wayleaves to dig up roads, or whether they can negotiate running their fibres down motorways, railways, power lines, or across fields. For instance, when i worked for Cable & Wireless in the 1990s, in the UK we had the “figure-of-eight” trunk network which was based on laying fibre down the East Coast and West Coast railway lines between London, Bristol, Birmingham, Glasgow and Edinburgh. Some of these routes were more than twice as long as the crow-flies distance.
You can actually see the different “hops” on the network between you and the endpoint using a traceroute tool. Each hop is, nominally, a router. Often networks will set up a system which constantly “pings” other locations so you can see the transit latency between various cities on their network. Here’s an example: Ping time between Paris and other cities - WonderNetwork
When I checked this just now, the average round-trip latency between London and Paris on this network was just over 9ms, which isn’t bad. But the Internet is “best effort” so if circuits get busy this can spike. And, remember, this is just between core networks in the major cities, which is typically where all the ISPs connect with each other. You still have to add in the latency of the ISPs network at each end, including the connection to your house.
A lot also depends on how the various parties manage their networks, particularly with respect to peering (connecting to other networks). I would try to explain how this works, but it’s actually a highly technical subject; I have a couple of small books covering just the basic technical aspects:
Suffice it to say, the peering agreements do not always follow the lowest-latency routes; often what decides how your data gets routed is down to economics.
At one point I was intimately involved in this stuff on a day-to-day basis running a team whose job it was to manage peering relationships and the associated BGP4 policies and configuration[/quote]
There are YT vids of people jamming using this kit.
$150 on Amazon + $8.35 shipping to U.K. Claimed import duty $0.
Also available as a kit.
This unit is uses a Raspberry Pi.
Also can be used to implement Jamulus as well as the JackTrip software, which is also an open source project.
If you’re interested in learning about it I’d start here:
I did say in my last post that I didn’t feel musically competent to invite others to collaborate but…I’m very keen to explore this if there is anyone who could put up with my limitations.[/quote]
[quote=“Majik”] Yes, I’m familiar with Jacktrip. I messed around with it once across my own network.
It does it in a good way to minimise latency, using peer-to-peer. Any time you have a central server you introduce additional latency as you have to from each person to the server and back again.
However, a central server also provides something that is tricky with peer-to-peer: latency compensation. The trouble with peer-to-peer is that each the latency between peers can be different. For instance, We could have 10ms between me and you, but it might be 30ms between me and Toby, and 40ms between you and Toby.
To a degree this doesn’t matter if the latencies are low, but I’m not sure how this works in practice. I also doubt the overall latency between Toby in France and us in the UK would be significantly lower than it could be with Jamulus.
I also think $150 plus shipping is a lot to spend on something that’s quite speculative.
I actually invested in the JamKazam JamBlaster kickstarter a few years ago. I think that was around $200. This was a similar unit to the JackTrip Virtual Studio. I received the hardware, but actually finding and arranging jams with people online was difficult and they eventually seemed to sink into obscurity and the hardware was abandoned.
Because of this, I’m a bit sceptical about investing in something like this.
And therein lies the rub: I actually think the hard part of this even if you solve the technical implementation side, is arranging productive jamming sessions with other people. I take my hat off to Rossco for the OM stuff, but I think something similar for jamming would be harder to organise and maintain.
I’m also using my experience of bell ringing here which, because of COVID, has largely gone online using tools like Ringing Room. Here the technical barriers are much lower and the tools are excellent, and most of the groups already existed in the real-world and have been meeting on a weekly basis for years. Despite this, many of these groups, including the one I am in, have stopped meeting online.
Quote
I did say in my last post that I didn’t feel musically competent to invite others to collaborate but…I’m very keen to explore this if there is anyone who could put up with my limitations.
For my own part, I’m willing to try again, now I’m back in the UK. My main issue is finding time to do it. I spend far too little time with my family as it is at the moment. Also, I think a challenge is deciding what to play.[/quote]
[quote=“Majik”] The issue here is we have a hard limit in the speed of light. Unless most of what we understand about Physics is completely wrong, then the speed of light is a hard limit.
London to Cape Town is approx 10,000km giving an absolute minimum round trip time of 40ms. The real-world practical rtt due to the speed of light alone is likely to be well over 100ms, due to fibre routes not being as the crow flies. The current average ping time is over 250ms.
These numbers are just way too high for real-time jamming, and always will be.
There is the option for “delayed sync” applications, like Ninjam, although I’m not sure how effective these are. If you aren’t sure what they are, this document explains it pretty well:
Quote
Delayed Sync applications are great for unstructured jamming, “noodling” on an instrument, and learning to improvise, but not good for playing through an entire song end-to-end or as a replacement for in-person band/chorus rehearsals. These applications solve latency by increasing it, from hundredths of a second to multiple measures.
Of course, the other option is to jam with more local musicians via a local server.[/quote]
