Get Started

If you are able to perform all the tests on this page successfully you’ll have no problem using our service. If you are considering a subscription, we strongly suggest you run at least the Internet connectivity test on this page. Someone may have shared this page with you if they are already a subscriber and want you to check if you’ll be able join them in their syncspace to perform together.

Testing, Testing, 1, 2, 3

To begin, please ensure you have read Tech Requirements and have the gear including a computer, an Ethernet cable, an audio interface, and a webcam.

The next step is to run the Internet connectivity test. This is critical and must be done.

If you are not sure whether you computer can run the audio software, or if you have never used an external audio interface before and you have one now, we recommend running also running the audio test. The final test checks whether you can use your webcam and run the real-time video service.

1. Internet connectivity test

Why you need to test and how to test

Why you need to test latency: Performing together across the Internet is highly dependent on achieving low latency between your location and the server you are connecting to. You need to measure the time (in milliseconds) to send data to one of our servers and receive data back. This is the roundtrip (two-way) network latency. While we’re at it, we’ll also confirm upload and download bandwidth but bandwidth is rarely a problem with any decent broadband (DSL/cable/fiber) connection. Click on one of the region links on this page to test your Internet connectivity to a test server in that region. Where multiple options are offered in a region (e.g. Toronto or Toronto 2), please test against all options.

Why everyone in an ensemble needs to test: If there is a set of people you want to perform together with regularly, please have all of them test to the same region. Especially because of poor Internet routing with some Internet Service Providers (ISPs) in some cities, you may find that some people in your ensemble may get very low latency to a servers in that region while others trying the same test might have high latency because all their traffic is going out of town and coming back. In these cases the people with low latency may have to change ISPs or you may want to all agree to use another region where you can all get roughly the same latency even if it’s not the very lowest.

Please take careful note of the instructions at the top of each test page. Tests must be run through Ethernet to be valid. Wi-Fi can lead to poor performance. To be 100% sure you are connected to Ethernet, turn off Wi-Fi in your computer settings. If you don’t currently own an Ethernet cable you can run the test on Wi-Fi just to see if you’re in the ballpark. Depending on how good or bad your Wi-Fi is, you can expect the latency might be 1 or 2ms slower but the jitter will likely be a lot worse. Wi-Fi is not a supported configuration for using our service.

Also pay attention to jitter measurements: Jitter is the variance in the latency. If your jitter is high, it means there is instability in your connection. Most connections should have less than 3ms of jitter. While high jitter could be caused by other devices on your home network using the Internet while you are testing, it could also be caused by problems with your networking hardware including cables. The best results will come from the most direct connections to your Internet modem.

The critical importance of optimal Internet routing

Every location where we are deployed in is carefully selected for the lowest possible latency and this is often a matter of ensuring maximum peering through Internet Exchange Points (IXPs). In some cities there are ISPs that not peered locally. If you are with one of these ISPs you may find that traffic between you and a local server may be routed out of the city and back, even when the server is just down the street. It may work out that the lowest latency you can get will not be to one of our servers in your city but in another city. If this is the case, you may have to either change ISPs or settle for higher latency to another region. The testing page for each region describes how to confirm if you might have problematic Internet routing.

Known issues with Internet routing

Examples of the issues we are aware of with ISPs failing to keep local traffic local:

  • Ottawa, Canada; Rogers, TekSavvy, CanNet, Acanac, Start, and Virgin route all traffic via Toronto (or worse). If you or any people in your ensemble are using one of these ISPs it’s probably best to use a Toronto server. Bell will route directly to our Ottawa servers with 2 – 5ms roundtrip network latency. Videotron and NCF will also route correctly.
  • Portland, Oregon: Comcast routes all traffic via either Seattle or San Jose.

With these kinds of situations, it may mean that it is best to use a server in a different city. For example, if everyone in an ensemble is getting 5ms to the server but some people are getting 30ms because their traffic is being routed out of town and then back, it may be best to locate the server in one of those cities that the traffic is going through so that everyone gets roughly equal latency even though it might not be as low as it could be for some people. These routing problems with ISPs are beyond our control and we already put in a huge amount of effort to locate our strategically in the most central places with the best peering so that we can offer the lowest possible latency for the largest number of people in that city.

If you need help sorting things out or you have more information to add regarding problematic routing in one of our regions, please feel free to contact us.

Performing together between different cities

It is entirely possible to perform together between cities as long as you understand the limitations. In fact we will soon be demonstrating inter-city performances with professional musicians at our virtual venue. Performing between cities where one or more performers are more than 200 miles or 330 kms from a server is absolutely possible but the delay between sending and receiving sound will increase with the distance. Cities that are close together are quite workable even for playing in time at moderately fast tempos. Cross-continental or inter-continental collaborations will place greater limitations on what you can do together. If you are trying to setup collaboration between performers in different cities, choose a location that is as equally distant from all the ensemble members as possible. Have each performer run tests to the region that is most central for everyone and use the calculator on this page to enter the roundtrip latency you get from the test to understand what it might sound like to perform together with longer distances.

Syncspace.Live Regions

Test your latency to any of the regions below


Canada

Ottawa

TorontoToronto 2 / Toronto 3

Vancouver
(also try Seattle)

Beta:

Kitchener

Coming soon:

Montreal

Calgary

Edmonton

Winnipeg

Halifax


USA

Seattle

FremontSan Jose

Los Angeles

Portland

Dallas

Chicago

Atlanta

Miami

Washington, D.C.

New York

Newark

Beta:

San Diego

Coming soon:

Honolulu


Europe

London / London 2

Dublin

Beta:

Frankfurt / Frankfurt 2

Munich

Nuremberg

Falkenstein

Helsinki

Amsterdam

Zurich / Zurich 2

Coming soon:

Paris


Asia-Pacific

Sydney

Melbourne

Brisbane

Perth

Making sense of the measured network latency

The network latency is not the only factor in the overall delay you hear when performing together across the Internet. There is also some time spent processing the audio data and getting sound in and out of your computer. This is one of the reasons why a low-latency audio interface is also an important part of the solution. Typically this additional time is about 10ms with the most aggressive settings on Jamulus. It can be even less with JackTrip.

What’s a great number? If you can get 5ms or less for roundtrip network latency the overall delay will be so short it will be virtually undetectable. It will allow you to perform with others without limits, even performing music at very fast tempos of 300 beats per minute or higher.

How high can you go? The short answer is about 40ms for roundtrip network latency. Everyone will have a different tolerance for delay and it depends on what you are trying to perform. It’s often said that you can tolerate up to 25ms of one-way delay (50ms roundtrip delay), which is like being approximately 28 feet apart. However the distance from one side of a large choir or orchestra to the other side will often be even greater.

What to do if your latency is high: If you measure roundtrip network latency that is somewhere between 15 and 40ms, it doesn’t mean you can’t perform together, but it will place some limits on what you can perform. This will be more noticeable if you are trying to perform music at very fast tempos together. As describe earlier on this page, in some cases it is possible you will see latency that is higher than expected. This can be due to many things but one of them can be that your Internet Service Provider is incorrectly routing your traffic out of town even though the server is located nearby.

Enter the average roundtrip network latency from running the speedtest into the calculator below. We have included a typical time of 10ms to process audio (both ways) but you can change this if you wish. This will give you an idea of what it would sound like if you were performing in the same room with others.

2. Audio connectivity test

In this section we’ll test your audio setup. The goal is simply to determine whether you can run the software and send and receive audio through your hardware. We won’t try to tune the setup for audio quality or latency and instead of connecting to an audio server in a syncspace, you’ll connect to a local server that you will run on your computer.

Firstly determine whether you want to test using Jamulus or JackTrip. JackTrip can be tricky to setup and tune and while the latency can be slightly lower and the audio quality higher than Jamulus. Jamulus is a much easier option to start with and for many people the latency and audio quality will be more than good enough.

Connect your audio gear to your computer

Sending audio

We strongly recommend using an external audio interface to both send and receive audio but if you really want to try using a USB microphone this is a possible option discussed below.

Using an external audio interface

If you are playing music you should use an external audio interface with your computer for higher quality audio and better control over your sound. Two excellent units are the Focusrite Scarlett 2i2 and the M-Audio Air 192 | 4. Both have very high-quality sound, low latency, and controls that are easy to adjust.

If you are playing an instrument that plugs into your audio interface directly, you may also want a microphone to speak to other members of the ensemble or a viewing audience. To do this you will need an audio interface with two channels.

Using a USB microphone

A USB microphone is essentially a microphone with some of the functionality of an external audio interface.

USB microphones can potentially work with Jamulus or JackTrip but they don’t offer as much predictability as an external audio interface and there may be limitations and additional complications.

While the latency of audio interfaces is usually well known and easily measured and manufacturers typically design them for low latency and will claim low latency, the latency of a typical USB microphone is never typically advertised.

There is another problem which is that while all USB microphones can send audio into your computer, most have no way to also function as an output device. Although some USB microphones do have a headphone jack, many of these only use the headphone jack to monitor the sound going into the computer through the microphone and can’t be used for sound output from the computer. If the USB mic has some kind of mix control then it may be able to handle output.

If the USB mic has no output, you can, in theory, use the headphone jack in your computer to receive sound, even though it may add latency and the sound quality might not be the best. However, this means that you will need to use one device for input (the USB microphone) and a different device (the computer headphone jack on the computer) for output. This is easy to do on a Mac but more involved on Linux and even more involved on Windows and generally it is not a path we recommend.

The bottom line is that USB microphones are a bit of a crapshoot. We strongly recommend using an audio interface for the best results.

Receiving audio

You will normally use headphones so that the sound coming back from the server is not picked up by your microphone. If you do not do this it will likely cause a feedback loop for other members of the ensemble.

If you are using an audio interface with a headphone jack it is usually best to use it to receive sound instead of using the headphone jack in your computer. If you are trying to use a USB microphone instead of an audio interface, it may not have an audio output and you may have no choice but to use the headphone jack in your computer.

Jamulus (the easier option)

a) Download and install the Jamulus software

If you don’t already have Jamulus installed on your computer, download it for Windows, Mac, or Linux here and install it on your computer.

b) Run a local Jamulus Server

On Windows or Mac, start the Jamulus Server application. On Linux, run the Jamulus executable with the -s option.

If you are running on a Mac and get the message that the application cannot be opened because the developer cannot be verified, go to your System Preferences (in your Apple logo menu) then go to Security & Privacy and on the General tab you will see a way to tell the Mac you are okay to launch the application.

c) Run the Jamulus Client

Make sure your audio interface is plugged into your computer.

Run the Jamulus client.

If you are running on a Mac and get the message that the application cannot be opened because the developer cannot be verified, go to your System Preferences (in your Apple logo menu) then go to Security & Privacy and on the General tab you will see a way to tell the Mac you are okay to launch the application.

d) Connect to the local Jamulus server

  1. Click the Connect button in Jamulus and the connection dialog will appear.
  2. In the Server Address field of the connection dialog, type 127.0.0.1 then click the Connect button under the server name field.
  3. You should see Jamulus immediately connect to your local server. A connection should appear in the Jamulus window and an entry should appear in the list at the top of the Jamulus Server.

e) Setting the right audio device(s) in Jamulus

In the main Jamulus window, click the Settings button. In the window that appears, make sure you have the right audio devices selected for input and output under the Soundcard Device options. If any of your devices have multiple channels, you will also see options to select specific input and outputs.

On some platforms such as Mac, different combinations of input and output will be listed. If you are using an external audio interface you should select the device options so that you are using the audio interface for both input and output.

If you are using a USB microphone: As discussed above at length, USB microphones are not the ideal path but can work in some cases. If you are using a USB microphone that does not handle audio output and you are running on a Mac, you can select the USB mic for input and your computer’s headphone jack for output. Doing this on Windows or Linux is much harder and while it is possible we don’t recommend it as it involves additional software and configuration.

It is critical that you make sure you are sending and receiving through the right devices. If you are testing through a microphone, the best way to ensure that you are sending your external microphone to Jamulus and not the computer’s internal microphone is to gently tap on your external microphone so that the noise is not so easily heard by the computer’s microphone.

In the main Jamulus window you, ensure you have Mute deselected above your name. You should be able to hear yourself in the mix coming back from the server.

Set Audio Channels to “Stereo” and Audio Quality to “High” to improve the audio quality.

f) Confirm that you can change the settings through Jamulus

In this test we are only trying to confirm that you are able to use your audio interface with Jamulus. In the setup guide for each syncspace there is detailed information on tuning. However it is important that you verify that you are able to change the Buffer Delay in the Jamulus settings window. If these options are disabled, it is possible you don’t have the right driver or the latest driver for your interface or your interface (or driver) does not have the ability to change the buffer size. If the driver for your interface doesn’t allow the buffer size to be changed by Jamulus, there may be options to change the buffer size in the software for your interface. You want to, ideally, have the ability to change the buffer size to 64. Also make sure your sampling rate is set to 48 kHz.

It should be possible to reduce the difference between the Ping Time, as displayed in the Jamulus settings window, and the Overall Delay, to approximately 10ms by setting the buffer delay to 2.67ms (or setting the buffer size to 64 in the software for your interface), checking the Enable Small Network Buffer option, and possibly also unchecking the Auto setting for the Jitter Buffer and manually reducing the buffer sizes.

g) Stop Jamulus and the Jamulus Server

After you have successfully tested the audio, exit both the Jamulus client and the Jamulus Server.

JackTrip (better sound but harder to configure and tune)

a) Download, install, and configure JackTrip (and Jack)

If you don’t already have JackTrip working on your computer, you will find the software for Windows, Mac, or Linux here, along with instructions for installation and configuration. There are dependencies that need to be installed on all platforms so that in the end you will usually have to run other programs such as Jack/QJackCtl/jackd, in addition to JackTrip itself.

b) How to use Jack and JackTrip

As you’ll read in the instructions at the download site, JackTrip uses Jack and Jack needs to be configured using QJackCtl for Mac and Linux or the Jack Control app on Windows. When JackTrip is run you will see that there are audio connections that need to be made between JackTrip and the playbacks on your audio interface, and similarly between between the captures on your interface and JackTrip.

If you have one or two playback (output) channels and one or two capture (input) channels, the connections to them will be made automatically for you when you run JackTrip. However, if you have multiple audio interfaces and/or more than two channels, you may find that if the connections you need to make are not the first two inputs and outputs, then you’ll have to manually make the right connections. This can become a pain when you have to do it every time you connect to the server. One way to make things easier is to use a simpler setup with a one or two-channel audio interface. On the Mac, you’ll see there is an optional JMess program that can be used to save the audio assignments. It’s important to understand that the pairs of channels correspond to left and right in a stereo field. If you only have a mono input you should link this to both channels so that you’re sending the same signal to both the left and right

c) Setup jack/jackd

Run qjackctl first and click the Setup… button to open the settings dialog. Make sure you have 48000 entered for Sample Rate and 64 entered for Frames/Periods as these are the settings for our JackTrip servers.

d) Run a local JackTrip server

In a command prompt, terminal, or shell, run this command to start a local server with echo: jacktrip -S -p4

e) Connect to the local server

In a second command prompt, terminal, or shell run this command to connect to your local server: jacktrip -C 127.0.0.1

Adjust your connections in the qjacktl Connections window so that you are able to hear the echo of your own audio.

f) Stop the JackTrip client and the JackTrip server

After you have successfully tested to a local server, you can stop both the JackTrip client and server by hitting Ctrl-C or simply closing the command prompt, terminal, or shell. You can then also close QJackCtl or the Jack Control window.

3. Video connectivity test

For this test we’ll confirm that you can use your webcam and run the real-video service in your web browser. If the webcam built into your computer is not very good, you might want to get a low-cost 1080p webcam especially if you will be broadcasting your performances.

Click on this link to open a page that will lead you through a video test. Normally when Jamulus or JackTrip are used for audio, the video service is used with the audio disabled. However you can test it with your camera audio if you wish.

All done?

If you were successfully able to run all the tests, you’re all set! You’re ready to signup for a subscription or join someone else in their syncspace and start performing together across the Internet! If you run into issues and have questions, feel free to contact us.