Most new people who try out Jamulus and join our servers would complain about the latency (especially professional musicians), to which I give the same advice: 1) Use a fiber-optic internet service. 2) Use a LAN cable. 3) Use wired headphone (no bluetooth/wireless headphone/AirPods). 4) Use an audio interface with ASIO device or use a Mac. Finally, and most important: 5) Just play 100 songs on Jamulus, and you’ll eventually get used to it.
Most friends are jamming with latency of around 20ms. I have found that for vocals and drums, maximum latency tolerance is around 30ms. For me I play the keyboard and most of the time I’m jamming over a 4G mobile network, I have increased my latency tolerance to about 100ms now.
It's pretty wild to think about. My dad used to point out to me that, if I was watching a live concert on the TV, the sound would reach me before it reached much of the live audience.
I found that most of the latency in networked audio applications, when jamming within 800 km within domestic internet, mostly comes from (a) a large network buffer (to prevent sound stutter when the network isn’t reliable, e.g. due to wi-fi interference) and (b) extra audio processing on top (echo cancellation, noise suppression), and not the limitation of light speed.
You're vastly exaggerating. FTL communication is not here yet.
The theoretical limit for half the planet is ~67ms, in practice it's north of 100ms for Jamulus (plus the additional delay of a user's sound reproduction system).
I believe the example above is more about sound speed than light speed.
I experienced concerts in stadiums, in the back rows, where the distance from the stage makes the sounds arrive noticeably later than the visuals.
The delay is really perceptible, and disturbing, to a point.
A TV audience would not suffer from it (assuming a live broadcast, with negligible broadcast latency, for the example to make sense).
Apt-X "low latency" is 33ms - the equivalent of being about 11m away from the sound source.
Standard Apt-X is 100ms, or equivalent to 33m distance in open air.
SBC codec is 200ms.
Then there's the buffering headphone bluetooth chipsets may do to avoid customers complaining about clicking/popping. If you're on a crowded subway train there can be a shitload of bluetooth traffic bouncing around, in which case having a healthy buffer is helpful.
I have an external "headphone out and 2 microphone in" USB interface now, and it's latency is still in the 5-15ms range, so I use onboard to write and headphones to master. At one point I bought a macbook air and a FireWire interface, but the screen was no good and the single FireWire interface tied my hands. I also have a few pci cards that I've been collecting parts for, like an m-audio 8x8 interface, there's a box that connects to the back of the soundcard with some 30-40 pin d-sub. I finally got all 5 or 6 parts and don't really have a computer to put it in anymore! I wanted that card for around 10 years by the time I found all of it...
I'm assuming anything midi-ish can just use quantization and only the player will notice, the final mix should sound ok.
Every musical instrumented (voice too) has a latency. The practiced musician is trained on the latency of themselves and their instrument and will initiate a musical note at the right time. That might even be a few seconds in advance.
Part of learning an instrument is learning its latency. Jamulus adds a bit on top of that. That requires some getting used to. A good tip is to listen to your sound over the internet. So wear insulating headphones that keep out your real-time sound.
edit: replace hands with whatever is needed to produce the sound: vocal chords, mouth, feet, arm, ...
Playing from Thailand in a Singapore server, add 27 milliseconds.
Playing from Thailand in a Hong Kong server, add 65 milliseconds.
Next event scheduled for Dec 4th 17:00 GMT
...or GNU/Linux, where Jamulus on JACK works wonderfully with low latency and easy audio routing across apps.