By now we all know that there is a real challenge to successfully have rehearsals remotely unless you have significant funds. Yes the technology is there but at what price. Let’s for example use Jamulus as a tool to implement economically feasible remote rehearsals on the current Internet1. Most computers of recent vintage will be able to provide sufficient performance to run this app, so what keeps it from being a go to for rehearsals? Simple, the current Internet1 is the problem unless of course you have a budget for Internet2 and a reason to use it. Jamulus requires a client server architecture with the server playing the role of a mixer. Each client (musician or singer) sends an audio stream to the server and it is mixed and returned to each client. This is a simplified view but suffices for this explanation. The medium for communication is the Internet and it introduces a delay which for the most part is too long. This has been validated long ago by several tests at various companies and Institutions such as Stanford etc.. This of course was also a reason the AES has been working on protocols for more efficient audio transmission. The current acceptable overall delay is in the 20-30 ms max range for a successful rehearsal session. This is a challenge for most current Internet providers. This can easily be tested with long existing tools such as ‘tracert’ that will provide a chain of equipment that is involved to communicate with the server along with the delay times. This will give you an idea if you’re even close to meeting the requirements. Jamulus also will indicate the delay times of any server but as in most Internet protocols they are not deterministic and can vary in real time. Let’s look at the individual sources of delay and whether you can even correct for them. From the microphone or instrument to the computer and out to the Internet is controllable but represent a small fraction of the delay usually less than 2-5 ms. With the Internet1 however you have little if any control over it and represents a variable time delay up to several hundred ms. This is the real source of the problem since it is a round trip of audio streams. The server on the other hand like the client is not a significant delay source in the chain of no more than a few ms. This assumes that the server and its Internet connection is a real server not a client with a typical Internet connection. Most all ISP’s have the client connection as a asymmetric implementation meaning that download speeds are roughly 10 times the upload speeds. This would of course make matters worse for a server. A symmetric service is needed for a realistic server such as T1 or better. So what could help overcome the present Internet problem? Once the hype and marketing subsides and robust network is in place 5G may be the answer. Even the high speed 4G LTE may suffice but it is still spotty. The answer unfortunately is a trial and error solution but at least it is economically feasible. Download speeds are claimed to be in the 4-5 Gbs range and upload in the 2-3 Gbs range for 5G. Even half of that would be quite usable with the 5G backbone being claimed far faster than the current Internet1. Time will tell.
Please post any experiences that you’ve been part of to address this problem.
Cheers
