Creating and Running a Jamulus Server in Amazon EC2— A Practical Guide

You too can build a Jamulus server with fast network access that won’t cost an arm and a leg

What this article covers

In this article I will discuss the options for setting up and running a Jamulus server in AWS, then focus specifically on EC2. I will cover example costs for running a Jamulus server, creating a server and installing the Jamulus software, options to get a static IP address or hostname for your server, recording your Jamulus sessions, retrieving the recording files and enabling automatic nightly shutdown to save money,

I will also cover starting and stopping the server, changing the server size (up for more power or down for lower cost), monitoring the server load and network usage, monitoring your AWS spend, viewing the Jamulus server logs, applying security patches and upgrading to new versions of Jamulus.

I’m not going to describe how to configure your Jamulus client software on your local computer, there is good documentation and plenty of forums discussing it. I am only going to consider how to build and operate your Jamulus server.

Why did I write this?

I am a member of London City Voices, a community choir based in London and we have been operating remotely during lockdown. For the most part, we’ve been using Zoom for rehearsals, but they’re very much a one-way street with Richard Swan, our choir Director, “broadcasting” with us singing along at home, while muted.

We’ve started experimenting with Jamulus, an audio collaboration tool designed for low-latency, to be able to experience singing together again, which is all but impossible using systems like Zoom because of their significant audio delay and in-built correction and “catch-up” algorithms.

Richard, following Simon Tomlinson’s excellent Idiots Guide to Installing or Upgrading a Jamulus Server on Amazon AWS Lightsail Ubuntu instance with help from Stephen O’Reilly built a Jamulus server on Amazon Lightsail. This works really well and convinced us that Jamulus was the tool we wanted to use.

If you’re considering running your own Jamulus server I would recommend you read Simon Tomlinson’s guide. Using Lightsail will give you a fixed monthly cost (£5 per month for example) and the same benefits of using AWS — namely fast network and low cost.

Lightsail will likely suit most people’s needs. However, when we looked at the size of server we would need to scale to the number of people in the choir we thought would be interested, we realised that the Lightsail server size we would need would cost quite a bit of money (comparison below), and we would be better off using Amazon’s EC2 service with its pay-per-minute pricing and only switching the server on when we needed it.

That’s when I started looking at building Jamulus instances in EC2.

Who should read this?

This article is aimed at people who want to build a private Jamulus server in EC2, rather than Lightsail, for the reasons I mention above, and who aren’t afraid of using a command line. I’ll explain all the things you need to do and type, so even if you’re not an experienced Linux user, you should be fine.

If you don’t fancy building your own server, look out for a future article on how you can use a pre-built EC2 server image, based on what I describe here, to run Jamulus in AWS.

Thanks

I must say thanks to the creators of Jamulus and all the contributors to the wiki and other documentation that is out there on the internet. Also to Simon Tomlinson and Stephen O’Reilly for the wisdom and guidance they have given Richard and London City Voices. It is great to be able to use near real time audio for remote singing and jamming with such relative ease.

Some Terminology

• Amazon refer to their virtual servers as instances. I will likely use the terms interchangeably. Sorry!
• Disks are also known as volumes. The type of Amazon disk storage we must use for our servers is known as Elastic Block Storage, or EBS.
• Elastic IP addresses are static IP addresses for Amazon EC2.
• Not strictly terminology, but I’m giving examples of editing files using nano to make it easier for beginners. Don’t shoot me; I’m a vi guy in my day job.

Amazon Web Services (AWS)

AWS Account

You will need access to an AWS account. If you don’t have one, you can create one very easily, but I won’t cover that here. I am assuming that your AWS account still has the default VPC and all its associated networking, i.e. you haven’t deleted anything. If you have, you probably know what you’re doing, so you’ll be able to spot where you need to make changes in my steps below to suit your account.

Choosing your AWS region

The whole point of Jamulus is low network latency, so choose an AWS region that is closest to you. If you need help determining which region that is, you could use a tool such as Cloud Ping.info which tells you the ping time from your browser to each AWS region. Remember, you’re looking for the lowest value.

AWS Costs for a Jamulus server

When done well, using AWS EC2 can be considerably cheaper than renting a dedicated server of equivalent power. I am making my recommendations in this article, but obviously your AWS spend is your responsibility and you should research the EC2 pricing for yourself, specifically on-demand instances (the “server” cost), EBS storage (the “disk” cost) and network traffic. I will give examples some below. My examples are all for the London region, though they’re still charged in US Dollars, and may change over time. I also might get my maths wrong, don’t sue me.

The size of instance you choose and how many hours you run it for have the biggest impact on the cost. Next will be how large a disk you choose to connect (disk charges are 24x7), and then the networking cost, which is based on the amount of network traffic, but that should be pretty negligi ble.

Another cost that might be incurred is that of static, or “Elastic” IP Addresses, but these are optional, as explained in the next section.

Compute

We decided we needed an m5.2xlarge instance (8 core, 32GB RAM), which has an hourly cost of $0.444. This equates to a compute cost of $320 per month. The equivalent Lightsail instance would cost $160 per month all-in, so we’re paying double if we leave it running 24x7. Of course, we won’t be leaving it running 24x7, we’ll be using it for around four hours a week, which means the cost is more like $8 per month. If we used it five nights per week that would still only be $40 per month. However, with EC2 you pay for more than just the running server time.

If you wanted to start smaller, you could use a t3.micro instance (2 core, 1GB RAM) which has an hourly cost of $0.0118. This would equate to a 24x7 compute cost of $8.496 per month, or just 20¢ per month if you used it four hours a week.

I will explain below how to set an automatic late-night shutdown on the instance in case you forget to switch it off.

Disk storage

Disk storage is included in the Lightsail price, but for EC2 you have to pay for it. Amazon call this Elastic Block Storage, or EBS. You pay for your disk 24x7, regardless of whether the server is switched on.

The base operating system and Jamulus software come to about 3.5GB, so will fit easily into the default 8GB you get, so with an EBS gp3 disk costing $0.0928/GB-month in London, that equates to $0.74 per month. Not huge. You’ll also get about 4GB of disk space free for recordings.

If you want to store lots of recordings, you will need to pay a bit more for a larger disk. How much disk space you need will depend on:

1. The Length of recording(s) you want to make before downloading them from the server and deleting them
2. How many people are connected during the recording
3. The quality settings in Jamulus, which define the file size

Using mono (as we only have one microphone) at “normal” quality, each person takes about 6MB per minute. So to sing for five minutes with 50 people would take up 1.5GB. During an evening, we might make several takes, or just leave the recording on to be cut up later, so having plenty of headroom is ideal. In stereo, these numbers all double.

Increasing the disk size to 80GB would increase the storage cost to $7.40 per month.

Network

A big chunk of network traffic is included in the Lightsail price, but for EC2 you have to pay for it. You only pay for network traffic outbound, i.e. data sent from your AWS server. Inbound traffic to your server is free. The first 1GB per month is free, after that it is $0.09 per GB, up to 10TB, after which it gets slightly cheaper.

As an indication, we pay about $8 per month on network traffic, which covers both Jamulus sessions and pulling down the recordings.

Total server cost

All in all, the example m5.2xlarge Jamulus server running four hours per week and with the network traffic I describe is going to incur a monthly cost of approximately $24, comprising $8 on compute, $7.40 on disk and $8 on network. That’s a decent saving on the $160 Lightsail bundle for a server of the same power.

If you went for the smallest viable option, the t3.micro, with a handful of Jamulus users and without any additional disk space, you’d be paying $2-$3 per month, comprising $0.20 on compute, $0.74 on disk and probably a dollar or two on network.

As I mention above, these are just my estimates based on 4 hours of use per week. You should do your own maths for your particular situation and using the AWS pricing for your chosen AWS region.

“Static” IP Addresses (optional)

Amazon offer Elastic IP Addresses, which act very much like static IP addresses, in that they don’t change. This means your choir members or bandmates don’t need to change their settings every time the server is stopped and started up again. Even better, if you control an internet domain (e.g. yourcompany.com) you can add a DNS record referencing the un-changing IP address so people only need to type a hostname (e.g. jamulus.yourcompany.com) into their Jamulus settings, rather than typing an easily mis-typed string of numbers.

However, Amazon’s Elastic IP Addresses incur a cost when the server is not running (yes, you read that right — it is to discourage people from hoarding them) so I will instead offer an alternative, which is to use the free service Duck DNS. This gives a DNS hostname (myjamulus.duckdns.org) which can update whenever your server starts. The end result is the same, and you can still add a DNS record (a “CNAME”) pointing to the Duck DNS one, to give you a hostname in your own domain if you wish.

How to setup both Amazon Elastic IP Addresses and the free Duck DNS alternative are explained later on.

An Elastic IP address costs $0.005 per hour when not in use by a running server, which equates to a maximum of around $3.72 per month in the London region.

Initial AWS Setup

• Login to the AWS console and select EC2 (you’ll find it listed under Compute. Alternatively, type EC2 into the search box at the top)
• Ensure you are in the AWS region closest to you. In my case, this is London (dropdown, top-right)

Select your AWS region

• Next you’ll need to create or add an EC2 Key Pair (unless you already have one in your chosen region). To create a new key pair:
  - Click on Key pairs
  - Click the Create key pair button, top-right
  - On the Create key pair screen, enter a suitable name, e.g. EC2London and click Create key pair
  - Your browser will now prompt you to download a file called EC2London.pem (or whatever you called your key pair). Save this file somewhere safe on your computer. Do not share it with anyone unless you want them to access your server. You will not get another chance to download this file. If you lose it, you will need to create a new one and recreate the server you are about to build. Please take care not to lose it.

Create an EC2 key pair

• On the left-hand side, choose Instances, found under the Instances heading. Click on Launch Instances, top-right

Click to launch a new instance

Instance Configuration

You will now be presented with a series of steps to configure and launch your instance. The instance size and disk sizing will depend on how you will use your server. See my discussion of costs in the AWS Costs for a Jamulus server section above.

• Step 1: Choose an Amazon Machine Image (AMI) — scroll down to Ubuntu Server 20.04 LTS (HVM), SSD Volume Type, which was fourth on the list, and click Select

Choose Ubuntu Server 20.04 LTS (HVM) as your server type

• Step 2: Choose an Instance Type — Choose whatever instance size you have decided upon, e.g. t3.micro and click “Next: Configure Instance Details”
• Step 3: Configure Instance Details — leave everything at the defaults and click “Next: Add Storage”
• Step 4: Add Storage — The default 8GB is more than sufficient for the operating system and the Jamulus software. If you are not going to add any additional disk space for recordings, leave the root volume size at 8GB. Otherwise change the 8GB to whatever size you wish. Please note you cannot reduce the size below 8GB.
• Change the Volume Type to the slightly cheaper General Purpose SSD (gp3). Do not be tempted to adjust the IOPS or throughput settings as these will incur additional cost.

Select gp3 storage at a size of your choosing

• Click “Next: Add Tags”
• Step 5: Add Tags — While optional, a tag with key Name makes it easier to identify your server later, so click Add Tag and enter a Key of Name (capital “N” is important) and a Value of Jamulus and click “Next: Configure Security Group”

Add a Name tag to your EC2 instance for easier identification

• Step 6: Configure Security Groups
• Leave the option to Create a new security group selected
• Change the Security group name to Jamulus and the Description to Jamulus server security group
• Change the default SSH rule to have a source of My IP via the dropdown menu. The IP address should change to your own.
• Click Add Rule and a new row will appear
• In the new row, select a Type of Custom UDP Rule and a Port Range of 22124 with a source of Anywhere
• Optionally, add a description to each of the rules (see screenshot)
• You should end up with something like the below

Security Group configuration for Jamulus with SSH

• Click “Review and Launch”
• Step 7: Review Instance Launch — Click Launch
  When prompted to Select an existing key pair or create a new key pair, choose the key pair created earlier (mine was named EC2London). Then check the acknowledgment box and click Launch instances
• You should see a message that Your instances are now launching

Your instance is launching

• Click View Instances, bottom-right
• In the Intances view, check the checkbox to the left of your server’s name and look below in the Details tab for its Public IPv4 address:

Find your server’s public IP address

• Note down the Public IPv4 address, we will need this shortly. Tip: You can click the icon to the left of the numerical IP address to copy it to your clipboard

Connecting via SSH

From MacOS

Before we connect to the server instance, we have to adjust the permissions on the key pair file we downloaded earlier. Hopefully you’ve put it somewhere safe and it’s not just sitting in your downloads folder.

Open Terminal and type:

chmod 600 /path/to/EC2London.pem 

(substituting /path/to/ with the folder path to your .pem file)

Then we can use that file as our identity to connect to the ubuntu user on the instance

ssh -i /path/to/EC2London.pem ubuntu@<public IP address of instance>

(again, substituting /path/to/ with the folder path to your .pem file) e.g.

ssh -i Documents/EC2London.pem ubuntu@18.130.45.168

All being well, you should get a remote session on the instance.

From Windows

If you are using Windows, you will need an SSH program like PuTTY to connect to your instance. Rather than repeat good information that is already available, I will refer you to Amazon’s page Connect to your Linux instance from Windows using PuTTY.

All being well, you should get a remote session on the instance.

Ubuntu updates

Now we’re connected to the server, bring all packages up to the latest available versions:

sudo apt update
sudo apt upgrade

When prompted with Do you want to continue? [Y/n], hit <return> to install the updates.

Jamulus Setup

Jamulus build and install

Update: As of version 3.7.0, Jamulus has been available as .deb packages and while these may seem simpler, I found that they lack the flexibility of user and group configuration to simplify retreiving recordings (covered later on) and they don’t use systemd. Also, using .deb files actually made these instructions more complicated, because we need to worry about version numbers in downloads and filenames. I’ll keep an eye on things, hoping for a deb repository we can pull directly from in future.

I installed Jamulus following the instructions on the wiki: https://jamulus.io/wiki/Server-Linux, specifically the Compile sources, create a user section, choosing a headless configuration.

In short, you first need to install some prerequisites:

sudo apt install build-essential qt5-qmake qtdeclarative5-dev qt5-default qttools5-dev-tools

Again, when prompted with Do you want to continue? [Y/n], hit <return>

Now let’s build Jamulus:

cd /tmp
wget https://github.com/jamulussoftware/jamulus/archive/latest.tar.gz
tar -xvf latest.tar.gz
cd jamulus-latest
qmake "CONFIG+=nosound headless" Jamulus.pro
make clean
make
sudo make install

Next, create a user for Jamulus. Here we deviate slightly from the Jamulus documentation in that we also create a group with the--group flag, so that we can more easily manage recordings, as described later on.

sudo adduser --system --group --no-create-home jamulus

Add the ubuntu user to the jamulus group

sudo usermod -a -G jamulus ubuntu 

Make Jamulus start on boot

In order to make Jamulus start at system statup, we need to configure a new systemd service.

As root (i.e. using sudo), add a new file at /etc/systemd/system/jamulus.service . You can do this with the nano editor:

sudo nano /etc/systemd/system/jamulus.service

Add the following lines to this file:

[Unit]
Description=Jamulus-Server
After=network.target
[Service]
Type=simple
User=jamulus
Group=jamulus
UMask=002
NoNewPrivileges=true
ProtectSystem=true
ProtectHome=false
Nice=-20
IOSchedulingClass=realtime
IOSchedulingPriority=0
ExecStart=/usr/local/bin/Jamulus --server --nogui \
--recording /home/ubuntu/jamulusrecordings \
--norecord \
--log /dev/stdout \
--serverinfo "JamulusServer;London;224" \
--welcomemessage "<h3>Welcome to the Jamulus server</h3>" \
--numchannels 100 \
--centralserver localhost
Restart=on-failure
RestartSec=30
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=jamulus
[Install]
WantedBy=multi-user.target

Save the file and exit with Ctrl-x followed by y. Press enter to confirm the file name.

Then tell systemd to start Jamulus at system boot.

sudo systemctl daemon-reload
sudo systemctl enable jamulus 

(note Jamulus hasn’t been started yet)

The logging configuration in the file above is a little different to that in the Jamulus documentation. I’m doing this because I want all the Jamulus logs to end up in one file, rather than spread between a Jamulus logfile and syslog’s main logfile. To complete this, we also need to add an additional configuration file at /etc/rsyslog.d/30-jamulus.conf to tell syslog where to put the logs. Again, using the nano editor:

sudo nano /etc/rsyslog.d/30-jamulus.conf

Add the following lines to this file:

if $programname == 'jamulus' then /var/log/jamulus.log
& stop

Save the file and exit with Ctrl-x followed by y. Press enter to confirm the file name.

Once it’s up and running, all of the Jamulus logs will now end up in the file named /var/log/jamulus.log

Add a directory to store recordings

Creating the jamulusrecordings directory with these permissions, along with the group configuration above, means that the ubuntu user you login with has full control over the audio files that are produced. Therefore a graphical SFTP client like FileZilla can be used to pull the files down to your desktop computer and delete the files once they’ve been retreived, without having to login to the server via SSH and use sudo to delete them.

mkdir /home/ubuntu/jamulusrecordings
sudo chown jamulus:jamulus /home/ubuntu/jamulusrecordings
sudo chmod 2775 /home/ubuntu/jamulusrecordings

Adding a script to make enabling/disabling recordings easier

Telling the Jamulus server to start and stop recordings is done via Unix signals. To make this a bit easier, I have created a script at /usr/local/bin/jamrec . Create this file with the nano editor:

sudo nano /usr/local/bin/jamrec

and add the following lines:

#!/bin/bash
JAMULUS_PID=$(systemctl show --property MainPID --value jamulus.service)
if [ ! -z ${JAMULUS_PID} ]; then
  kill -s USR2 ${JAMULUS_PID}
else
  echo "Cannot find a running Jamulus server"
  exit 1
fi
JAMULUS_LOG=/var/log/jamulus.log
if [ -f ${JAMULUS_LOG} ]; then
  /usr/bin/grep "Recording state" ${JAMULUS_LOG} | /usr/bin/tail -1
fi

Save the file and exit with Ctrl-x followed by y. Press enter to confirm the file name.

Next, make this script executable (so it can be run like a program):

sudo chmod 755 /usr/local/bin/jamrec

See the sections Toggling Jamulus recording on and off and Retrieving recordings from the server below for how to use this script once you’re up and running.

Reboot

At this point it is sensible to reboot to make sure everything is working as intended and that everything starts up on system boot. Nothing is worse than using a server for months then it reboots and something won’t work. Let’s deal with all that now while the concepts are fresh in our minds.

sudo reboot

After the reboot, reconnect with SSH, as you did above. Note, the IP address of the server will not change on a reboot, only after a shutdown.

Automatic Shutdown

To prevent accidental costs being incurred if you forget to shutdown your instance, you can add a scheduled “cron” job to stop the server at a certain time. If the server is still running at this time, it will be stopped. If the server isn’t running at that time, it has no effect.

To achieve this, we need to edit the file /etc/crontab as root:

sudo nano /etc/crontab

Use the down arrow to move the cursor to the bottom of this file and add a new line containing:

55 23 * * * root /usr/sbin/shutdown -h +5

The time definition in a cron entry can seem a little opaque, but is explained in many places, including here on Wikipedia. The above entry says “at 55 minutes past the hour of 23” (i.e. 23:55) “every day, of every month, regardless of the day of the week, have the root user run the shutdown command with 5 minutes’ warning”.

In short, it shuts down the machine at midnight. Obviously, you can tweak the timing to suit your needs.

Save the file and exit with Ctrl-x followed by y. Press enter to confirm the file name.

Optional static hostname option 1: Duck DNS

Whenever you start your EC2-based server it gets a new public IP address. A free way to get a hostname for your server that never changes, so that your choir members or bandmates don’t have to change their Jamulus settings each time you start your server, is to use Duck DNS. It is a free service that you have to register for. There are similar services avaiable and the choice whether to use one or not is yours.

• Once registered, choose to add a domain, selecting which hostname in the duckdns.org domain that you wish to use. I chose jimjamulus.duckdns.org :

Duck DNS control panel

• Note the value of your token towards the top, we will need it in a moment.
• Next, create a new file at /usr/local/bin/duckdns.sh. You can do this with the nano editor:

sudo nano /usr/local/bin/duckdns.sh

• Add the following lines to your new file, including the - at the end.

echo url="https://www.duckdns.org/update?domains=YOUR_HOSTNAME&token=YOUR_DUCKDNS_TOKEN&ip=" | curl -s -k -o /var/log/duckdns.log -K -

• Replace the value of YOUR_HOSTNAME with the hostname you chose above, not including the duckdns.org part (In my case: jimjamulus).
• Replace the value of YOUR_DUCKDNS_TOKEN with your Duck DNS token, noted above. Be careful not to add any spaces when you paste in your token.
• You should end up with something like this:

echo url="https://www.duckdns.org/update?domains=jimjamulus&token=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX&ip=" | curl -s -k -o /var/log/duckdns.log -K -

• Save the file and exit with Ctrl-x followed by y. Press enter to confirm the file name.
• Make this script executable:

sudo chmod 755 /usr/local/bin/duckdns.sh

• Next, we need to tell the server to contact Duck DNS at reboot and inform it of its current IP address. Duck DNS will then update the DNS record, so your chosen hostname will resolve correctly to your server.
• Edit the file /etc/crontab with you favourite editor:

sudo nano /etc/crontab

• Scroll down with the arrow keys and add the following line at the bottom of the file:

@reboot   root    /usr/local/bin/duckdns.sh > /dev/null 2>&1

• Save the file and exit with Ctrl-x followed by y. Press enter to confirm the file name.

The next time you reboot, after a short delay (less than one minute) you will be able to use your chosen hostname (e.g. jimjamulus.duckdns.org) in the Jamulus settings on your computer.

Add your chosen hostname to your Jamulus settings

You can also use this hostname when you’re connecting via SSH:

ssh -i /path/to/EC2London.pem ubuntu@jimjamulus.duckdns.org

(substituting /path/to/ with the folder path to your .pem file)

Optionally, if you have your own domain, you can create a CNAME record in your DNS to your Duck DNS hostname, e.g.:

jamulus.yourcompany.com → jimjamulus.duckdns.org

That way, your choir members or bandmates will be able to use the hostname in your domain and not have any idea Duck DNS is involved.

Reboot now for the Duck DNS settings to take effect and to ensure everything is configured correctly:

sudo reboot

Optional static hostname option 2: Amazon Elastic IP address

If you don’t want to sign up for a service like Duck DNS and are prepared to pay a little extra, you can use an Amazon Elastic IP address. As I explained earlier, one of these will cost you a maximum of $3.72 per month in the London region; you are charged $0.005 per hour while the server is not running. Once attached to your instance, its public IP address will never change, meaning you can reliably use that IP address in your Jamulus configuration, or add a hostname in your own domain, e.g. jamulus.yourcompany.com that resolves to the Elastic IP address.

To attach an Elastic IP address to your instance, first we allocate an address from Amazon’s pool, then we associate it with our instance.

• Go to Elastic IPs in the EC2 console and click the Allocate Elastic IP address button:

Allocate an Elastic IP address

• On the Allocate Elastic IP address page, leave all details as they are and click Allocate

Elastic IP address allocation details

• Back on the Elasic IP addresses screen, note down your new Elastic IP address.
• Check the box next to the new Elastic IP address and click the Actions menu, then select Associate Elastic IP address:

Associate an Elastic IP address

• Leave the Resource type as Instance, then click in the Instance box and it should show you a list of your instances. Select your Jamulus server instance. Click Associate.

Elastic IP address association details

Now your Jamulus server has a static IP address, which you can use in your Jamulus config, or in a DNS entry within your own domain.

That’s It — we’re all set!

Ok, so it probably seemed like quite a bit of fiddling about, but you now have a solid server to run Jamulus, with a few additional features, like the auto-shutdown, DuckDNS and an easy mechanism to record your masterpieces and get hold of the files. Below I will explain how to use the server on an ongoing basis.

Using your server day-to-day

Starting the server

• Login to the AWS console and select EC2 (you’ll find it listed under Compute. Alternatively, type EC2 into the search box at the top)
• Ensure you are in the AWS region closest to you (dropdown, top-right.) In my case, this is London
• On the left-hand side, choose Instances, found under the Instances heading.
• You should see your instance listed.
• Check the box to the left of its name, click the Instance State menu at the top and click Start instance

Start your instance

After a few seconds your instance will be running.

If you have not chosen to use the Duck DNS or Amazon Elastic IP address options, you will need to look in the summary box to find the Public IPv4 address of you server for your Jamulus settings, as this will change every time you start it up.

Stopping the server

You stop the server in an identical manner to how you started it, only selecting Stop instance from the Instance state menu:

Stop your instance

Alternatively, if you are already connected to your server with SSH (perhaps to start/stop recordings) you can simply type:

sudo shutdown now

Checking CPU and network usage

You can check graphs for the levels of CPU, network and other resources consumed by your instance. This will give you an indication of whether your server is struggling and whether you need to change to a different instance size.

The graphs can be found in the same place you go to start and stop your instance. Once you’ve checked the box next to your instance name, click on the Monitoring tab below to see the graphs. Note you can also choose your time range in the top-right above the graphs.

View your server’s CPU and network usage

Checking your AWS spend

It is important to keep an eye on how much you are spending on your cloud computing account. AWS will send you a bill at the end of every month, but you can check your current month’s spend at any time by logging into the AWS console, clicking your name (top-right) and then clicking My Billing Dashboard:

Accessing the AWS billing dashboard

The Spend Summary (lower middle) is a graph showing your previous month’s and current month’s spend so far in blue, plus a prediction of the total for the current month in green. The Month-to-Date Spend by Service (right) shows a pie chart of the different AWS services you are spending money on in the current month so far. Below this is a table of those services and the amounts spent on them so far this month:

An example AWS Billing & Cost Management Dashboard

Clicking Bill Details, top-right, will allow you to dig deeper into this month’s bill so far or any previous month’s actual bill.

Switching instance sizes

You may wish to change the size of your instance to make it larger (for more capacity) or smaller (to save cost). Your server must be stopped to make this change.

As before, go to the EC2 console, check the box next to your server name and click on the Actions menu, then click Change instance type:

Change instance type (size)

You will be given a menu of available instance types to choose from. Once changed, the next time you start your server you will be running on the new instance type, with the new per-minute price from that point onwards.

Making logging in to the server via SSH a bit easier (Mac/Linux)

As before, we use the key file as our identity to connect to the ubuntu user on the instance

ssh -i /path/to/EC2London.pem ubuntu@<public IP address of instance>

(substituting /path/to/ with the folder path to your .pem file)

If you wish to make this a bit easier to type every time, you can add some lines to a file called to .ssh/config on your local Mac / Linux machine

First create the directory, if it doesn’t already exist:

mkdir .ssh

If it comes back with an error ending File exists, that’s ok. It just means the directory is already there and we can continue.

nano ~/.ssh/config

If the file already has some lines in it, just add the new lines at the bottom:

Host <handy name>
  User ubuntu
  Hostname <Your Duck DNS hostname or your Amazon Elastic IP address>
  IdentityFile /path/to/EC2London.pem

Substituting:

• <handy name> for a single word name you want to call your server, e,g, jimjamulus
• <Your Duck DNS hostname or your Amazon Elastic IP address> for your Duck DNS hostname (e.g. jimjamulus.duckdns.org) or your Amazon Elastic IP address (e.g. 1.2.3.4)
• /path/to/ with the folder path to your .pem file. Note it has to be a full path from the root of the disk (/) OR it can be relative to your home directory if you start with ~ , e.g. if it was in your home directory: ~/EC2London.pem or if it was in your Documents folder: ~/Documents/EC2London.pem

You should end up with something like this:

Host jimjamulus
  User ubuntu
  Hostname jimjamulus.duckdns.org
  IdentityFile /Users/Jim/Documents/EC2London.pem

Save the file and exit with Ctrl-x followed by y. Press enter to confirm the file name.

Now, all you need to type is ssh <handy name> e.g.:

ssh jimjamulus

And it will automatically add the username, the hostname and the key file.

Toggling Jamulus recording on and off

If you installed my script above, all you need to do to toggle recordings on and off is to type:

sudo jamrec

Toggle recording on and off

You will also see when recording is active via the message at the top of the screen in Jamulus itself.

Jamulus with recording active

Recording files will be placed in the folder at /home/ubuntu/jamulusrecordings which is visible as the folder called jamulusrecordings as soon as you login. See below for how to download these files to your desktop computer.

Retrieving recordings from the server

If you have made some recordings, the chances are you’ll want to listen to them. In order to do this, you need to transfer the files from the server to your local computer. You could use the command line scp program (or PuTTY’s pscp on Windows), but the simplest way is to use a graphical file transfer program that supports the SCP protocol. I would recommend FileZilla — it is a little old in its design, but still maintained and perfectly reliable.

Installation and configuration of FileZilla

• Download FileZilla for Mac/Windows/Linux — get the “non-Pro” version, i.e. the free one
• On MacOS: click the downloaded file to open it and and drag the FileZilla app to your Applications folder.
• On Windows: follow the installation instructions here
• Open FileZilla
• Go to File menu -> Site Manager
• Click the New Site button
• On the left, where the title New site appears, change it to something like Jamulus server
• On the right, select the protocol as SFTP — SSH File Transfer Protocol
• For Host enter your server’s IP address or hostname
• Select a Logon type of Key file
• For User enter ubuntu
• For Key file, browse to the .pem SSH key file we saved earlier

Configure a connection in FileZilla

• Click Connect
• When prompted, tell FileZilla not to remember passwords
• When told about an Unkown host key, check the box Always trust this host, add this key to the cache and click ok
• You should see a directory listing on the right-hand side, including a folder called jamulusrecordings

Retrieving and deleting recordings using FileZilla

Once configured, all you need to do is:

• Go to File menu -> Site Manager and double click your Jamulus Server connection on the left.
• On the Remote site panel (right-hand side), double-click the folder named jamulusrecordings

The jamulusrecordings folder, shown in FileZilla

• There will be a folder per recording, with a name starting Jam- and the date and time that it was started. Simply drag the folders across to the left-hand side and the files will be copied to your local computer.
• Remember to delete the recording files from your server once you’ve downloaded them by right-clicking the recording folders starting Jam- and selecting delete. Be careful not to delete the top-level jamulusrecordings folder itself. If you do accidentally delete it, login via SSH and recreate it as described in Add a directory to store recordings, above.

Ubuntu updates

To keep your server secure, you should periodically (at least monthly) log in to the server via SSH and run the same update commands we ran at the start:

sudo apt update
sudo apt upgrade

When prompted with Do you want to continue? [Y/n], hit <return> to install the updates.

Viewing the Jamulus logs on the server

The logs are stored at /var/log/jamulus.log

To view the log, use the less command:

less /var/log/jamulus.log

This will start you at the top of the file. To get straight to the bottom, type a capital G . You can use the up and down arrow keys to move through the logs.

Upgrading Jamulus

From time to time, new versions of Jamulus are released and we may want to use them for their features or bug fixes.

To ensure we have a way back if the new version doesn’t work out, create a backup:

sudo mv /usr/local/bin/Jamulus /usr/local/bin/Jamulus.old

Then install the new version as we did before:

cd /tmp
wget https://github.com/jamulussoftware/jamulus/archive/latest.tar.gz
tar -xvf latest.tar.gz
cd jamulus-latest
qmake "CONFIG+=nosound headless" Jamulus.pro
make clean
make
sudo make install

Then we can restart the Jamulus service to start using the new verison:

sudo systemctl restart jamulus

You could check the new version is running by checking the logs (see above for full explanation of the logfile):

grep Version /var/log/jamulus.log

Make sure you use a capital V on Version . It may show several lines from the different times Jamulus has started; the most recent is at the bottom.

If you don’t like the new version, you can go back to the old one with:

sudo mv /usr/local/bin/Jamulus.old /usr/local/bin/Jamulus
sudo systemctl restart jamulus

The end

Happy Jammin’

Jamulus in action