Author Topic: Hardware limitations critical to Jamulus usage  (Read 1551 times)

WK154

  • Door #3
  • Master
  • *****
  • Location: Valencia CA
  • Posts: 2643
Hardware limitations critical to Jamulus usage
« on: February 25, 2021, 02:43:58 AM »
    Delay and indirectly synchronization prevent the effective use of Jamulus, let me explain. The accepted value of 20-30 ms of round trip delay (not Ping Time) would be the goal which is similar to a chorus rehearsal environment based on sound travel time (1ft/ms) to the director or member to member ( a range of 2-30ms depending on distance) along with synchronization errors.
Let’s follow the path sound takes thru the Jamulus system. From the singer to the microphone one could expect a delay of 1ms for every foot away from the mic. Proper use of a mic would make that about 1-4 inches or less than 1/12th to 1/3th of a ms (millisecond). Travel from the mic through a preamplifier and analog to digital conversion is usually under 1 ms. Transmission to the computer via USB adds no more than a 1ms. Next would be a buffering and digital conversion from USB format to Ethernet packet in the computer and out to the router/modem. This would add not more than another 2-5 ms depending on the performance of the computer and router/modem. So far it’s a little delay in the average amount of about 4.3 ms.  This portion is somewhat under your control with the purchase of the right hardware but it will have little effect on the overall experience as you will see.
    The next phase is where the real issue exists, your ISP (Internet Service Provider) and the Internet. The topology of the Jamulus system is a classic star configuration with the server as the center and clients (Jamulus users) individually communicating with the Jamulus server. The servers job is to combine all the communication (sound in this case) and sending it back to the clients (individual Singers/Musicians). Here again the processing/mixing and buffering time for a reasonable server is only 3-5 ms. So where is all the delay coming from? Unfortunately it’s from a source you have little control over. A little history is required here. The ARPAnet/Internet was designed to provide a robust communications means during a Nuclear War. Routing around affected areas was a design goal. This is what you now have, which means that each packet of information can take a different route to its destination, to both server and client. This can also lead to out of order arrival times of data (streaming sound in this case). This all needs to be sorted out by the server and clients adding some delay due to buffering. This still doesn’t explain round trip delays in the 40+ms range. The problem is with the route taken by a packet of information. Tracing the route on the internet from the client to the server and back reveals the problem. Your packet may go thru 10 to 30 Internet equipment's each adding to the overall delay even if it’s only 1ms per device. This can add up to 20-60ms round trip and add 8.6ms for your computer (both directions about equal to reach you Headphones) and the server with another 3-5ms adds up quickly. It is however quite clear that the bulk of the delay rest with the Internet routing. If you are lucky enough to have all your members on the same ISP within a limited geographic range you will most likely reduce this delay time to make the rehearsal tolerable. One member off by 20-30ms will severely affect this making muting this member necessary.
    Server location and its Internet service is of course a potential problem. For instance my Spectrum service of 400Mbs only specs download speed and not upload speed which is around 25Mbs. For a server the lowest speed will determine the number of users that it can handle. In my case of 25Mbs. with high quality audio it requires 0.726Mbs for streaming speed without dropouts. In theory I should be able to handle 34 clients but factoring in REALITY makes that about 60% of the total or 20 clients. For large groups of 50+ the minimum upload speed needs to be 100Mbs or better along with equal or better download speed. A more common solution is to lease a Cloud server from the many Cloud service providers and locate your server on it. This will at least remove the speed issue to the internet. Check with them for speeds provided that will serve your needs. There is a up and coming service now in major cities in the USA that provide for real time applications such as Jamulus. Two in the LA area I am aware of are AWS local zones and VOLTR high speed service. These will limit the amount of equipment in the path of you and the server reducing the delay. The other solution eventually will be 5G broadband service with claims of 1-2ms delay in theory. Right now Verizon list it at 34ms but test show 50ms so they have a ways to go. Its claim to fame is mobility since some broadband modems are designed for travel. Satellite service is at around 20Mbs and great for remote locations where there are no other Internet services.
    There are some upcoming changes to Jamulus V3.7 that may be of interest to some. Since the Genre on public list servers (5 all total to serve the whole world) only handle 150 server entries each and with the popularity of this app a need to add more capacity ended up splitting classical from chorus/barbershop and adding another list server. This was completed end of January but I haven’t seen it up yet. Possibly since the originator (Volker Fisher) of Jamulus has taken a much deserved rest from this task. A reshuffle in responsibilities is no doubt underway causing release delays. My observation of these servers over the past 9 months has the usage to about 5% and the squatters not releasing their spot makes it difficult to add more servers. Use of private servers will not affect this limitation. Most groups are only in 2 to 20 member range as well. There is some discussion about removing unused servers but not now. All public servers are shared even if they state “private” but please observe their reserved time which should be in their welcome message. If they don't want others to use their server they should make them private or remove themselves from the list when not in use  As a courtesy they will allow server usage by others when not in use by them. Always mute before joining any group as a common courtesy and not to destroy their session especially if your delay is large. Use the message board for any questions you may have.
Add “listener” to you name if you’re browsing sessions.

Post any additional information that would be pertinent to Jamulus use.

Enjoy

Some timings adjusted for buffering delays.
« Last Edit: March 23, 2021, 08:36:16 PM by WK154 »
When in doubt KISS

WK154

  • Door #3
  • Master
  • *****
  • Location: Valencia CA
  • Posts: 2643
Re: Hardware limitations critical to Jamulus usage
« Reply #1 on: March 01, 2021, 07:28:33 PM »
Here is an example of the typical delays found in contacting a server.

Tracing route to 108.61.219.200.vultr.com [108.61.219.200]
Over a maximum of 30 hops:
1   25ms      1ms      <1ms   RT-AX88J-63C8 [192.168.50.1]
2   9ms      12ms      10ms   142.254.183.101
3   11ms      12ms      10ms   agg63.sntlcaga01h.socal.rr.com [76.167.28.241]
4   22ms      15ms      14ms   agg23.chowadq01r.socal.rr.com [72.129.25.246]
5   11ms      11ms      11ms   agg24.lsancarc01r.socal.rr.com [72.129.25.0]
6   15ms      13ms      14ms   bu-ehter16.lsancarc0yw.tbone.rr.com [66.109.6.102]
7   14ms      21ms      22ms   bu-ehter11.tustca4200w-bcr00.tbone.rr.com [66.109.6.5]
8   *      *      *                           Request timed out.
9   46ms      45ms      45ms   ae-1-51.ear1.earl.LosAngeles6.Level3.net [4.69.210.93]
10   13ms      13ms      12ms   CHOOPA-LLC.earl1.LosAngeles6.Level3.net [4.26.2.142]
11   *      *      *                           Request timed out.
12   *      *      *                           Request timed out.
13   *      *      *                           Request timed out.
14   *      *      *                           Request timed out.
15   15ms      14ms      11ms   108.61.219.200.vultr.com [108.61.219.200]

Trace complete 

*This equipment has ping response disabled so no time can be determined.
The IP was given to test VULTR response.
As can be seen there are 14 pieces of equipment to traverse to get to a server.
Ping time for the above ranges from 14ms to 23ms.

This is to a cloud server at VULTR LA.
« Last Edit: March 06, 2021, 08:22:37 PM by WK154 »
When in doubt KISS

JohnMHoyt

  • Knight
  • ****
  • Location: Greenville, South Carolina
  • Posts: 341
  • Wherever you go, there you are
    • Hot As A Pepper Party & Event Band
Re: Hardware limitations critical to Jamulus usage
« Reply #2 on: March 12, 2021, 01:06:53 AM »
You lost me at 1/3th

WK154

  • Door #3
  • Master
  • *****
  • Location: Valencia CA
  • Posts: 2643
Re: Hardware limitations critical to Jamulus usage
« Reply #3 on: March 13, 2021, 09:12:35 PM »
Then you're the perfect candidate for a MusicBridge device. :)
Cheers
When in doubt KISS

WK154

  • Door #3
  • Master
  • *****
  • Location: Valencia CA
  • Posts: 2643
Re: Hardware limitations critical to Jamulus usage
« Reply #4 on: March 22, 2021, 04:07:25 PM »
Jamulus V3.7.0 is now available and a surprising number of public servers have been updated in just the few days. The one item that didn't make it in this release was QoS (priority of packets) feature that would certainly reduce delay time. This will have to wait for V3.7.1 unfortunately. There are other ways to add QoS to packets but I won't go into this here.
Cheers
When in doubt KISS