Latency isn't something we have an immediate feeling. Yesterday I was speaking on phone (cellular) about Jamulus configuration with a guitarist friend of mine. When he just reached to have his singer microphone working and I could ear him speaking in my loudspeakers, I was amazed to discover his voice in my speakers (via Jamulus, no WiFi at my friend's and no wifi on my side, both server and client) hit my hears about half a second (which is huge and very easy to distinguish) before is voice in my smartphone !
I couldn't beleive ! I'll always have this in mind when I'll give a call, because I've always had the feeling that people didn't wait I finish to speak to reply : now I wander if I'll use OVER or OUT in the end of my sentences.
This is not to say WiFi is as bad as cellular or the same thing, but keep that in mind. https://sourceforge.net/p/llcon/discussion/533517/thread/1877fcdc39/?limit=25#cf88
OVER or OUT
👍
3
Last edit: Gronaz 2020-03-26
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was trying to think of an analogy to help visualise the impact of latency.
If I have an overall latency of 40msec between playing my instrument and hearing it on my headphones (along with the rest of the band's instruments), then the equivalent for a band where everyone is in the same room is like having the loudspeakers you're all playing through placed 13.6 metres away. (Speed of sound is around 340m/s, so 40msec x 340m/s ~13.6m. This is about the width of the stage of a big theatre; you'd be on one side of the stage, your speaker would be on the other. Getting the latency as low as possible is really important and equivalent to getting your loudspeaker as close as possible to you (and everyone else).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Very good idea. Then my rough estimation of half a second leads us 170m away from our bandmates !
Being bidirectionnal this explains the phenomenon stated in the link above where each other trying to sync to the others, ends in the gig going slower and slower without the help of a deaf dreamer aka metronom or drum machine ;-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Interesting discussion here. I like the math that Tony to build a benchmark for network latency compared to physical sound latency on a stage. One thing for sure: no wifi or bluetooth anywhere in the Jamulus food chain (that includes bluetooth headphones), plus a dedicated device to convert analog connected instruments and microphones to the Jamulus client computer. I am trying to build a model that explains how many voices or instruments could be connected to a Jamulus Server without noticeable degradation.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am trying to build a model that explains how many voices or instruments could be connected to a Jamulus Server without noticeable degradation.
There's is a tendency to see the server as the main determinant of sound quality in a Jamulus session, when in reality it's almost the least significant factor in the vast majority of cases. Things like the client's buffer settings, ping time and even CPU are likely to start degrading a session much before anything the server can contribute, unless we're talking about running a server with, say, 10 clients on a 1MBit/s uplink.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Barry,
The sound quality does not depend on the number of clients.
It does depend on the quality of the Internet connection of each individual client.
If the noise comes from the up-link of a client to the server everyone on the server will hear it.
If the noise comes from the down-link to the client from the server only the single client will hear it.
Jamulus has no control over the communications quality. The main problem for the communications is the jitter or packets arriving out of order. Jamulus versions from 3.6.0 correct for out-of-order packets to some extent. In many cases that makes a big difference. Our only other possibility is to use the buffer size to allow more time for the communications. Sometimes reducing the sound quality helps too as it reduces the communications bandwidth necessary. In my experience, however, the bandwidth is rarely the problem.
Of course there is also the possibility that bad sound comes from a clients audio setup, sound card, micro etc.
(I have never really checked the sound of an overloaded server that can't respond in time. But that is not a normal usage case. That is why servers have a user limit. In any case it is easy to check the processor load of a server and make sure there is some headroom at all times by limiting the number of users. Or get a faster processor.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree with other comments... server has always been the least of my concerns when optimising for Jamulus. It's hard to construct a server that ends up as the bottleneck. Key is stability and latency in the client to server connection. In my experiments the things that made the biggest improvements to us for the quality of our band sessions were (in order):
Using a wired connection not wireless
Using an external soundcard (Focusrite, in my case)
Optimising where the server was physically hosted, depending on the mix of players and their locations/Internet connections (including hosted at home vs which AWS region I use)
Turning off cloud backup and OneDrive sync etc. during sessions
Upgrading the Internet router (in my case from Fritz 3490 to 7530)
Updating PC network drivers to manufacturer's latest, rather than Microsoft's best
Changing from FTTC to FTTP broadband with more than x10 bandwidth increase
Persuading others in the house to stop or reduce UHD streaming and game playing during a session (!)
Using noise cancelling hifi over-ear headphones (less distraction/more intimate sound)
Optimising PC network settings to minimise buffer bloat
Keeping Jamulus at both client and server up-to-date
Upgrading the disks used by my DAW (which I use with Jamulus to mix in virtual instruments - using a DAW in real time can be very resource intensive)
Setting Jamulus to low quality audio
At the start of lockdown in March I was seeing 40/100 mS up/down latency with long periods of buffer disruption. Now I expect to see a solid 20/40 mS performance with minimal or no buffer break-up. I live in Scotland: remotely hosted servers are mostly in London some 600 km away.
Things that made no or minimal difference:
Using Windows or linux for the servers
Increasing server spec in any dimension
Time of day
Last edit: Andrew S 2020-12-04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I gave up on on all the fiddling with settings and use my PC for Song Sheets, Zoom and Backing Tracks. You may see me rolling or unrolling a lan cable depending on the room I want to play in. Main thing is that my brain is happy under 60 feet = 60 ms . Any wiring is real wire = not virtual. Oh and I plugged in a Jambox so I could play with my American friends since I will not be going to Texas this winter.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Latency isn't something we have an immediate feeling. Yesterday I was speaking on phone (cellular) about Jamulus configuration with a guitarist friend of mine. When he just reached to have his singer microphone working and I could ear him speaking in my loudspeakers, I was amazed to discover his voice in my speakers (via Jamulus, no WiFi at my friend's and no wifi on my side, both server and client) hit my hears about half a second (which is huge and very easy to distinguish) before is voice in my smartphone !
I couldn't beleive ! I'll always have this in mind when I'll give a call, because I've always had the feeling that people didn't wait I finish to speak to reply : now I wander if I'll use OVER or OUT in the end of my sentences.
This is not to say WiFi is as bad as cellular or the same thing, but keep that in mind.
https://sourceforge.net/p/llcon/discussion/533517/thread/1877fcdc39/?limit=25#cf88
OVER or OUT
Last edit: Gronaz 2020-03-26
I was trying to think of an analogy to help visualise the impact of latency.
If I have an overall latency of 40msec between playing my instrument and hearing it on my headphones (along with the rest of the band's instruments), then the equivalent for a band where everyone is in the same room is like having the loudspeakers you're all playing through placed 13.6 metres away. (Speed of sound is around 340m/s, so 40msec x 340m/s ~13.6m. This is about the width of the stage of a big theatre; you'd be on one side of the stage, your speaker would be on the other. Getting the latency as low as possible is really important and equivalent to getting your loudspeaker as close as possible to you (and everyone else).
Very good idea. Then my rough estimation of half a second leads us 170m away from our bandmates !
Being bidirectionnal this explains the phenomenon stated in the link above where each other trying to sync to the others, ends in the gig going slower and slower without the help of a deaf dreamer aka metronom or drum machine ;-)
Interesting discussion here. I like the math that Tony to build a benchmark for network latency compared to physical sound latency on a stage. One thing for sure: no wifi or bluetooth anywhere in the Jamulus food chain (that includes bluetooth headphones), plus a dedicated device to convert analog connected instruments and microphones to the Jamulus client computer. I am trying to build a model that explains how many voices or instruments could be connected to a Jamulus Server without noticeable degradation.
There's is a tendency to see the server as the main determinant of sound quality in a Jamulus session, when in reality it's almost the least significant factor in the vast majority of cases. Things like the client's buffer settings, ping time and even CPU are likely to start degrading a session much before anything the server can contribute, unless we're talking about running a server with, say, 10 clients on a 1MBit/s uplink.
Hi Barry,
The sound quality does not depend on the number of clients.
It does depend on the quality of the Internet connection of each individual client.
If the noise comes from the up-link of a client to the server everyone on the server will hear it.
If the noise comes from the down-link to the client from the server only the single client will hear it.
Jamulus has no control over the communications quality. The main problem for the communications is the jitter or packets arriving out of order. Jamulus versions from 3.6.0 correct for out-of-order packets to some extent. In many cases that makes a big difference. Our only other possibility is to use the buffer size to allow more time for the communications. Sometimes reducing the sound quality helps too as it reduces the communications bandwidth necessary. In my experience, however, the bandwidth is rarely the problem.
Of course there is also the possibility that bad sound comes from a clients audio setup, sound card, micro etc.
(I have never really checked the sound of an overloaded server that can't respond in time. But that is not a normal usage case. That is why servers have a user limit. In any case it is easy to check the processor load of a server and make sure there is some headroom at all times by limiting the number of users. Or get a faster processor.)
I agree with other comments... server has always been the least of my concerns when optimising for Jamulus. It's hard to construct a server that ends up as the bottleneck. Key is stability and latency in the client to server connection. In my experiments the things that made the biggest improvements to us for the quality of our band sessions were (in order):
At the start of lockdown in March I was seeing 40/100 mS up/down latency with long periods of buffer disruption. Now I expect to see a solid 20/40 mS performance with minimal or no buffer break-up. I live in Scotland: remotely hosted servers are mostly in London some 600 km away.
Things that made no or minimal difference:
Last edit: Andrew S 2020-12-04
Regarding 8., I simply switch off WiFi in the home when playing :)
I gave up on on all the fiddling with settings and use my PC for Song Sheets, Zoom and Backing Tracks. You may see me rolling or unrolling a lan cable depending on the room I want to play in. Main thing is that my brain is happy under 60 feet = 60 ms . Any wiring is real wire = not virtual. Oh and I plugged in a Jambox so I could play with my American friends since I will not be going to Texas this winter.