I maintain couple of digital music teaching rooms. (instruments connected via audio interfaces, teachers switch cameras via elgato minis, etc.) We also setup Jamulus with a couple of students, by sending out 100$ equipment packages.
In Germany and it's mix of VDSL2 in the cities, ADSL on in the countryside and fiber for a couple lucky regions, Jamulus is a very mixed bag. If it works, it's magic, but the reality of infrastructure makes a recommendation hard, if you do not have an IT guy on staff.
Here is what we came up with:
Whilst professionals can deal with the delay (playing notes in the future) that comes from Jamulus with a suboptimal connection, Students can not. We misuse Jamulus' concept to create a workaround. We walk students through port-forwarding and students start the jamulus server via a script, that connects to our private jamulus directory server. Then the teacher connects to the students machine.
As a result, the student gets 0 delay and the teacher, with his experience has to carry deal with the delay and has to compensate for it. Huge pain to setup, but the quality of the lesson on the student's side does not suffer, even if the connection is bad.
On a funny side note, IRL I witnessed the exact opposite problem. A piano soloist professional was playing the Weichnachts Oratorium with the Kreuzchor choir I sang in. The soloist had to play the Harpsichord, which responds instantly (strings plucked under tension), as opposed to the Piano's hammmers, which have a "slight delay". The professional was so used to this "small delay", that he had to relearn and adjust a lot, because his professional experience with the piano produced too early timings with the conductor's actions. So the opposite of what teachers face with Jamulus.
I think when learning to e.g. play drums like I once did, another realization is that you need to start the motions well before the impact. Actually, this is what a lot of people that start warbling among with songs badly fail at - they try and follow along, but they need to start singing (or tapping) before the song they play along with does, which means they need to know the lyrics and what comes next already.
I remember a friend complaining that his USB keyboard synth "had too much latency" (from time pressing the key to hearing the attack from the windows speaker). I thought he was daft and then several years later, when we had a piano in the house, I tried it and immediately noticed that my USB synth had a significant latency (probably 100ms) which made it very hard to play. I discovered ASIO and was pretty blown away how high the default latency for USB to audio is on a modern OS.
It's exactly the opposite. Jamulus is far more mature, first release is from 2006.
The Sonobus UI is nice and responsive, coming from JUCE, but it's not native. More features, like metronome, are nice to have, but most musicians won't use them anyway as the instruments are usually connected through DAWs which provide all the necessary instruments for routing and layering sources.
The main difference is in the architecture, Sonobus is p2p, so it's great users have the option to try different approaches and find what works best for them.
Jamulus software is not only free (gratis and libre) but its use is completely anonymous: you may have to open a port but you don't have to open your inbox to spam or register in any way. And users don't need to authenticate to use a server, either "public" (i.e., advertised automatically in connection windows) or private (i.e., using an IP address known only to musical peers). There's no encryption but if you use a private server there's virtually no possibility of anyone other than designated peers to listen in.
I'm a so called semi-pro jazz bassist. During the pandemic, some friends invited me to join an online jam using Jamulus. So I learned some things.
I don't think that "latency" boils down to a single dimension, because there are multiple competing latencies when you play music. It's a complicated feedback loop with multiple input and output channels.
I think how well it works depends on being able to isolate the acoustic sound of your instrument from what's coming through your headphones. Your brain will prioritize whatever comes first, so if you can hear your own acoustic sound against the delayed sound of the band, you will instinctively slow down, and a band allowed to do this will grind to a halt. [0]
Electric instruments are easy, because they have little or no acoustic sound. I found it much easier to play solid body electric bass than double bass, though double bass is my main instrument. My hands adapted to the latency, as they do anyway because each instrument has inherent latency.
Winds and voice are difficult, because you hear yourself through bone conduction. Drums are hard to isolate with headphones. But people tend to (mistakenly) get the time from the drummer.
It fell to the electric instruments to "drive" the band. That was profoundly fatiguing. When I tried to take a solo, the band would get lost. And my solos can be blatantly rhythmic if I need them to be.
This is compounded by the fact that a lot of musicians are not techies, so the explanations about how they have to play differently, and work with the technology, goes over their heads.
[0] Imagine playing at 120 beats per minute, which is 500 ms per beat, with 30 ms latency. That's like 6% per beat. So while everybody says that 30 ms is pretty good, that much latency with the feedback loop described above will cause the band to lose tempo by 6% per beat. And 120 is a relatively stately tempo if you like "hot" jazz.
This reminds me of what happened on the first few weeks of trying out Jamulus. Every musician tries to match the tempo of other musicians. This results in the song gradually slowing down as you described. The next thing we realize is that we are playing songs at 50% speed.
So in the end we designated some instruments to drive the song. Usually its the drums. The person who drives the song must not wait for other instruments and keep their own tempo, and everyone else try to time their instruments to be in-sync with the drums. It works quite well for us.
Traditionally in jazz, the bassist provides the pulse, and the drummer provides color. This isn't true in all genres. And in a bigger band, the rhythm section (piano, bass, drums, guitar) has to function as a cohesive unit.
Although, optimally, the tempo just seems to sustain itself, a condition that's only met by the best players. Playing bass alongside a drummer with great time is certainly a better experience, and there are drummers with better time than me. Time is one of those things that's a lifelong pursuit, not something that is ever "good enough." Likewise intonation.
Using Jamulus, it seems to work best when the tempo is driven by instruments that can be isolated from the feed coming from the headphones, so for instance electric bass works better than double bass, though they both function as "bass."
The magical belief that p2p is always superior to server-client for this kind of application has to be refuted. I live in Kingston Ontario, a medium-sized city between Montreal and Toronto. There are essentially two high-speed ISPs: Bell, using fiber, and Cogeco, using cable. Latency between peers on the same network is usable, but packets from one network to the other, even a few blocks apart, are routed via, for example, Toronto to Chicago to New York to Montreal and finally back to Kingston. It's not the distance travelled that was problematical; it's the latency introduced at each intermediate node. By setting up a server at AWS in Montreal, the latency for peers on both networks became usable.
Also, p2p requires O(n^2) links whereas client-server has O(n) links, so if the number of peers increases, the total travel time difference will be more significant.
No matter what topology is used, the basic issue is the same: if any of the p2p links introduces unacceptable latency (such as the inter-ISP link I described), the whole system is borked. The clients are generally not movable (or would need to switch to another ISP) but a Jamulus server anywhere can be used or set up and may provide acceptable latency for all.
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.
Its baffling to think that the latency between computer and headphones might add multiples of latency added to the signal going hundreds of miles from one computer to another..
If you're sitting 5 meters from your speakers, you add about 15 ms of latency and, in some cases, people all the way across the globe will hear your sound before you hear it yourself.
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.
In case it wasn't clear, parent commenter probably means "don't use bluetooth headphones." There's no latency for wired headphones.
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.
USB soundcards were so featureful compared to onboard or even the pci stuff when they came out, like the sound blaster extigy. I liked positional audio and all of the spdif and toslinks. However, it, by itself, even with ASIO had latency up around 30-50ms.
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.
> I have increased my latency tolerance to about 100ms now.
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.
I'd say that listening to your own instrument with latency does not work at all. Making good tone/timbre/pitch etc all depend on a very short feedback loop between hands/ears/brain.
edit: replace hands with whatever is needed to produce the sound: vocal chords, mouth, feet, arm, ...
I know people who regularly used this for rehearsals during the pandemic (maybe they still do). I told them about it when it was previously featured here. They were thrilled. These were people that used to meet locally, so presumably the latency was relatively good.
Another group was interested, but the setup was too complicated for them (wired ethernet, messing around with asio). But if you can get beyond that, it's apparently pretty great. There might be a product idea there, a plug and play solution that avoids the manual setup.
Starlink could do significantly better in theory once the constellation of satellites with laser links is operational. The speed of light in vacuum is much higher than in optical fiber. If the data can be routed in space and travel directly from source to destination terminal instead of bouncing to and from ground stations then under 100 ms should be achievable. The light speed limit would be 50 ms (assuming that the data can't cut through the Earth's core).
It's unknown if Starlink will routinely route packets directly between user terminals or if that will be a special service sold only to customers willing to pay a premium. We'll see when the constellation is ready.
The increase in travel time comes from: extra path length from bouncing between the sides of the inner fibre (depends, maybe 20%?) and from refractive index slowdown (about 70%). But then you have to worry about the greater total path from going into space, and also mux/demux/boosting delays.
Readit News
Here is what we came up with: Whilst professionals can deal with the delay (playing notes in the future) that comes from Jamulus with a suboptimal connection, Students can not. We misuse Jamulus' concept to create a workaround. We walk students through port-forwarding and students start the jamulus server via a script, that connects to our private jamulus directory server. Then the teacher connects to the students machine. As a result, the student gets 0 delay and the teacher, with his experience has to carry deal with the delay and has to compensate for it. Huge pain to setup, but the quality of the lesson on the student's side does not suffer, even if the connection is bad.
On a funny side note, IRL I witnessed the exact opposite problem. A piano soloist professional was playing the Weichnachts Oratorium with the Kreuzchor choir I sang in. The soloist had to play the Harpsichord, which responds instantly (strings plucked under tension), as opposed to the Piano's hammmers, which have a "slight delay". The professional was so used to this "small delay", that he had to relearn and adjust a lot, because his professional experience with the piano produced too early timings with the conductor's actions. So the opposite of what teachers face with Jamulus.
I think when learning to e.g. play drums like I once did, another realization is that you need to start the motions well before the impact. Actually, this is what a lot of people that start warbling among with songs badly fail at - they try and follow along, but they need to start singing (or tapping) before the song they play along with does, which means they need to know the lyrics and what comes next already.
https://www.sonobus.net/
Maybe the Jamulus folks can combine forces with Sonobus folks, implementing any Jamulus features Sonobus lacks.
The Sonobus UI is nice and responsive, coming from JUCE, but it's not native. More features, like metronome, are nice to have, but most musicians won't use them anyway as the instruments are usually connected through DAWs which provide all the necessary instruments for routing and layering sources.
The main difference is in the architecture, Sonobus is p2p, so it's great users have the option to try different approaches and find what works best for them.
I don't think that "latency" boils down to a single dimension, because there are multiple competing latencies when you play music. It's a complicated feedback loop with multiple input and output channels.
I think how well it works depends on being able to isolate the acoustic sound of your instrument from what's coming through your headphones. Your brain will prioritize whatever comes first, so if you can hear your own acoustic sound against the delayed sound of the band, you will instinctively slow down, and a band allowed to do this will grind to a halt. [0]
Electric instruments are easy, because they have little or no acoustic sound. I found it much easier to play solid body electric bass than double bass, though double bass is my main instrument. My hands adapted to the latency, as they do anyway because each instrument has inherent latency.
Winds and voice are difficult, because you hear yourself through bone conduction. Drums are hard to isolate with headphones. But people tend to (mistakenly) get the time from the drummer.
It fell to the electric instruments to "drive" the band. That was profoundly fatiguing. When I tried to take a solo, the band would get lost. And my solos can be blatantly rhythmic if I need them to be.
This is compounded by the fact that a lot of musicians are not techies, so the explanations about how they have to play differently, and work with the technology, goes over their heads.
[0] Imagine playing at 120 beats per minute, which is 500 ms per beat, with 30 ms latency. That's like 6% per beat. So while everybody says that 30 ms is pretty good, that much latency with the feedback loop described above will cause the band to lose tempo by 6% per beat. And 120 is a relatively stately tempo if you like "hot" jazz.
So in the end we designated some instruments to drive the song. Usually its the drums. The person who drives the song must not wait for other instruments and keep their own tempo, and everyone else try to time their instruments to be in-sync with the drums. It works quite well for us.
I guess I’m a musician that makes this mistake. Where does it come from?
Although, optimally, the tempo just seems to sustain itself, a condition that's only met by the best players. Playing bass alongside a drummer with great time is certainly a better experience, and there are drummers with better time than me. Time is one of those things that's a lifelong pursuit, not something that is ever "good enough." Likewise intonation.
Using Jamulus, it seems to work best when the tempo is driven by instruments that can be isolated from the feed coming from the headphones, so for instance electric bass works better than double bass, though they both function as "bass."
Also, p2p requires O(n^2) links whereas client-server has O(n) links, so if the number of peers increases, the total travel time difference will be more significant.
I assume that it's not time-prohibitive either for each device not to be directly corrected to each other device.
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.
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.
Another group was interested, but the setup was too complicated for them (wired ethernet, messing around with asio). But if you can get beyond that, it's apparently pretty great. There might be a product idea there, a plug and play solution that avoids the manual setup.
It's unknown if Starlink will routinely route packets directly between user terminals or if that will be a special service sold only to customers willing to pay a premium. We'll see when the constellation is ready.