The free and open-source Jamulus app lets you play along with other musicians over the Internet in real time. We guide you through it.
Latency. Anyone concerned with trying to create live music over the internet will have become very familiar with that word. As I explain in my article 'How To Make Zoom Work For Music' (SOS June 2020), latency is like death and taxes; you can minimise it but you can't avoid it completely and normally it defeats attempts to play live together. As anyone who has tried it with the various video conferencing applications like Zoom and Teams will know it results in everyone being out of time with everyone else, with consequent cacophony!
So you may be as surprised as I was to learn there are a small number of applications where the developers refuse to admit defeat on this and are determined to allow musicians to play together live across the net. Among these are JamKazam, Soundjack and the subject of this article, Jamulus.
The first thing to note about these applications is that they all demand a lot of your environment in order to ensure the only source of latency they have to deal with is the Internet itself. You have to watch out for the following factors:
Hardware: A powerful computer is always nice to have, but these apps don't put too much demand on the host machine. Any decent computer from the last few years should do fine. For Jamulus, Windows, Mac and Linux are all good. Tablets and phones, unfortunately, are right out!
A separate audio interface is a necessity in order to provide a low-latency connection to the computer. In our own usage, UAD's Apollo hardware worked well, while a Blue Icicle XLR-USB adaptor wasn't so effective, adding pops and clicks. For Windows, Jamulus recommend an audio interface with a native ASIO driver. Decent microphones to plug into the interface give the best sound, obviously, and are well worth having.
You need a fast Internet connection. Jamulus specify a minimum of 1Mbps both up and downstream, but faster is better and a low ping time is essential.
Networking: You need a fast Internet connection. Jamulus specify a minimum of 1Mbps both up and downstream, but faster is better and a low ping time is essential. Jamulus recommend the ping time to the Jamulus server (see below) should be no more than 40ms, and the lower the (very much!) better.
All of these applications make the same recommendation with regard to Wi-Fi, and that is simply not to use it. You must set up a wired Ethernet connection between your router and computer. They don't mention Homeplug and other powerline solutions but I would be inclined to avoid them too if you possibly can.
Distance: That is, geographical distance between the participants. More on this below, but it is very important to be as close as possible, geographically speaking.
Headphones: You need them. Jamulus doesn't screen out sound from your mic the way that, say, Zoom does, so your speakers must be off or otherwise you're heading for feedback, big time.
Much of this would simply not be available to the average person, but is likely meat-and-drink to the readers of this esteemed magazine.
And so to the application itself. Jamulus is an open-source product developed under the GNU General Public Licence and, as befits such software, you don't need to create an account with anybody to use it! The way they achieve this is ingenious. The application has two parts: a server and a client. In order to work, a client has to attach to a server. It sends sound to the server and plays the sound it receives back from it. A server is a very simple beast in that any sound received by it from any attached client is bounced out to all attached clients.
Of course there's a little bit more to it than that and we'll talk about mixing the server performs later, but you'll see immediately that with a public server the idea of a private session is not possible. So connecting to a public server is fine if you're looking for a jam session to join in with and you like the idea of jamming with strangers, and indeed a lot of people use Jamulus for exactly that. But if what you want is to have a quiet little rehearsal with the rest of your band then it's not going to cut the mustard. The solution Jamulus have come up with is quite elegant and is known as the 'private server'. How this is achieved is another thing we'll be looking at later.
First we'll talk about the client and how you install and set it up. An installer can be downloaded from the Jamulus website. On Windows it will install both Jamulus client and Jamulus server; on the Mac you're offered a choice. You will always need the client but the server is only for if you are intending to run one. After installation, start the client and you'll see Screen 1 shown earlier.
This is pretty spartan, so you need to click on the Settings button on the lower left-hand side. This then gives you the Settings screen where lots of interesting stuff lives (Screen 2).
You can see I've set this up to use with my UAD Apollo. This is on a Mac, but if you're setting up on a Windows machine then you'll need to specify the ASIO driver — as mentioned earlier, a native ASIO driver is preferable. Jamulus permits two mic inputs per client, but as I'm using only one mic I've set both channels to it. I set the outputs appropriately, and that's just about all the setup I did. All the other settings I left at default.
There's a Profile page tucked away in the menus that you can use to provide a name for yourself and add the instrument(s) you play, which is useful for ID purposes, but by no means mandatory. Incidentally, Jamulus requires that you turn direct monitoring off for the live mics in your audio interface.
To make Jamulus actually do anything you must connect to a server, so click on the Connect button and you'll see something like Screen 3. This is a list of public servers, organised by latency with respect to you. You can see that at the time I was connecting (a Sunday morning) there weren't too many musicians around but a couple of servers had people waiting for others to play with. Once you've connected to a server, the appearance of the client suddenly gets richer (Screen 4).
There's a fader for each participant, including you, so that you can mix a balance for yourself to hear in your headphones. Note that the mix is actually performed by the server, which sends the resulting stereo mix down the line to you. Were the mix to be made at the client end then each client stream would need to be sent to you, requiring lots more data and potential for the streams to get out of step. Now you can start playing!
So you've had a good jam session but now you want a rehearsal with your band. Obviously you can't use a public server for this because anybody could gate crash your rehearsal. The answer is for one member of the band to install a private server. Running a private server is trivially easy, you just click on it and away it goes... Except for one thing: if you've started the server running on a computer on your own network then it will be inside your router's firewall. This means anybody outside your firewall (like your bandmates) won't be able to access the server. You need to open a port in your firewall; that's not nearly as bad as it sounds, but it does need careful explaining.
To most people the idea of opening a port in the firewall feels tantamount to opening the front door of your house and posting a sign saying 'Come in and help yourself!' It's nothing like as bad as that. An open port is not a risk as such, indeed there are quite a few ports open already in every firewall. There have to be, otherwise the Internet simply would not work. Port 25 is open for email transmission, for instance, and port 80 for Hypertext Transfer Protocol, which is what makes the World Wide Web work.
The Bad Guys are interested in open ports because whatever process of yours is running on the inside of the port receiving data through it ('listening', as they say) may have bugs or otherwise be vulnerable to attack. If there is no process running on the inside to receive data, the operating system simply throws away any incoming packets (including any sent by a hacker). That is, an open port is not like an open window. You can't just peer through. I only run the Jamulus server as a foreground application, and close it down when playing has finished, so it's not listening for very long and nothing else uses that port.
As a private server, Jamulus listens on UDP port 22124. On your router you need to open that port and set it to forward to the IP address of your computer on your own network. If that changes from time to time (such as if you're using DHCP), just set it to forward to all. Each router is different in how it lets you do this. Screen 5 is taken from the Jamulus website, and it shows the task being performed on a Linksys router, where it's called Port Forwarding.
Once you've got your private server running then you need to inform your bandmates of your public IP address on the Internet. (If you need to find this out then use the website http://ip4.me. It's quick, free and ad-free). When you and your bandmates start their Jamulus clients and click on Connect, you all ignore the list of public servers and, in the box down the bottom labelled Server Name/Address, you type that public IP address and click on Connect. Everything else being equal you will hear your bandmates in your headphones and you can get on with your rehearsal.
In our own band rehearsals, two of us are in the same building and the third is just 10 miles away. We do have a little latency (just enough to notice, like a very, very short delay and the odd pop or click), but in the main we are able to practice our songs quite successfully. To get some idea of the impact of distance on latency I arranged a Jamulus session with friend and studio owner Bob Bickerton in New Zealand (10am here in the UK, 9pm there). Bob had no problems setting up the Jamulus client or connecting to my private server. However, his latency was of the order of 300-400 ms. I don't know if you've ever tried talking with your voice sounding in your headphones delayed by one-third of a second, but it's next to impossible. So then we tried connecting to a public server that was geographically almost exactly midway between us (in Japan). Here we both had latency of getting on for 200ms. Conversation was just possible but playing music wouldn't have been, so we didn't try. One slightly strange effect we noticed was that any changes we made to the mix were also delayed by latency, so that on the high-latency servers, changes were delayed in a quite disorientating manner until we realised what was going on. This is due to the fact that the Personal Mix faders affect the mix at the server rather than at the client end.
Interestingly, a couple of times while we were connected, other people connected and then disconnected in a few seconds. Clearly people connect to public servers, and then if what they hear isn't what they're looking for they drop out quickly. This sounds like good etiquette.
So playing sessions with friends on the other side of the planet isn't quite here — yet.
Jamulus strikes me as a well-thought-out tool for making music across the Internet, but the great beast latency is not totally defeated, and there is a definite element of luck in whether it works out for you. Having said that, if you can put your hands on the hardware necessary then do give it a go.
I have not covered all the settings available for tweaking (see the Jamulus documentation for more information on that). It's hedged around with significant requirements and geographical restrictions, but with a little bit of luck and a following wind, and provided you stay fairly local, you really can play music in real time with other musicians across the Internet.