Jamulus ‒ Play music online. With friends. For free(jamulus.io)
jamulus.io
Jamulus ‒ Play music online. With friends. For free
https://jamulus.io/
63 comments
I like that little anecdote.
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 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.
And then there are pipe organs. Man, I don't how they do it, the latency is so big! Didn't know that about harpsichord though, that's interesting.
Other FOSS product that tries to solve the same problem and which worked a little better for us. (We tried both)
https://www.sonobus.net/
https://www.sonobus.net/
Wow. It's clearly a more mature, featureful project. The UI looks amazing, too.
Maybe the Jamulus folks can combine forces with Sonobus folks, implementing any Jamulus features Sonobus lacks.
Maybe the Jamulus folks can combine forces with Sonobus folks, implementing any Jamulus features Sonobus lacks.
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.
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.
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.
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.
> But people tend to (mistakenly) get the time from the drummer.
I guess I’m a musician that makes this mistake. Where does it come from?
I guess I’m a musician that makes this mistake. Where does it come from?
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."
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."
I think he means that in this case it’s a mistake as it would be wisest to take the tempo from the electronic instruments.
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.
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.
Doesn't that assume that you have a total mesh topology (rather than e.g. a ring) for p2p?
I assume that it's not time-prohibitive either for each device not to be directly corrected to each other device.
I assume that it's not time-prohibitive either for each device not to be directly corrected to each other device.
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.
While there is definitely some latency, we’ve found it to be bearable. Last week we just performed a jam session of 10 people live on the PyCon APAC online conference using Jamulus, and here’s the video clip: https://www.youtube.com/watch?v=rvb_n1fwH4E and one more https://www.youtube.com/watch?v=inGQdo1nrt0
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.
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.
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.
This.
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.
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.
> in some cases, people all the way across the globe will hear your sound before you hear it yourself.
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).
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).
FTS, not FTL.
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).
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).
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 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.
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.
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 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.
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, ...
edit: replace hands with whatever is needed to produce the sound: vocal chords, mouth, feet, arm, ...
Listening to your own instrument with latency is what makes it actually work and is essential for online jamming.
Those videos are great! Where were you all located, physically? I'm trying to get some sense for the geographical limits of this sort of thing.
Thailand. Ping time using fiber obtic internet is 4 milliseconds.
Playing from Thailand in a Singapore server, add 27 milliseconds.
Playing from Thailand in a Hong Kong server, add 65 milliseconds.
Playing from Thailand in a Singapore server, add 27 milliseconds.
Playing from Thailand in a Hong Kong server, add 65 milliseconds.
Thanks!
Hey! Those video clips sound great. I especially liked the first one. It’s really encouraging to see that people can make music together remotely.
You should check Jamulus WorldJam channel: https://www.youtube.com/c/WorldJam
Next event scheduled for Dec 4th 17:00 GMT
Next event scheduled for Dec 4th 17:00 GMT
Your jams are beautiful! Thanks for sharing! I can't believe this is actually possible at this quality.
> 4) Use an audio interface with ASIO device or use a Mac.
...or GNU/Linux, where Jamulus on JACK works wonderfully with low latency and easy audio routing across apps.
...or GNU/Linux, where Jamulus on JACK works wonderfully with low latency and easy audio routing across apps.
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.
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.
Tried it UK AU. Some latency cannot be fixed. It's 200ms class delay. Light speed gotta rise.
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.
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.
There is also an old project by one of the Winamp creators https://www.cockos.com/ninjam/
That's a little different. While Jamulus tries it's best to do realtime audio, ninjam works deferred.
Players agrees on a bpm and a number of bars, the software will record each bar and send to other that will cache them and then play them on the next loop.. so every player will hear others one phrase late.
(sorry for non precise terminology...)
I read somewhere that musicians can only tolerate up to ~20ms latency to be able to perform together “live”.
The speed of light gives you ~186 miles per millisecond, which assuming you need to make a round trip in 20ms gives you an upper distance of ~1900 miles for live performance.
In reality however this will be much lower due to processing overhead, speed of light in fiber (~0.7e), and internet backbone topology.
Curious to know if the creators have done any tests, (or can show any demos) of the effective range this works at?
The speed of light gives you ~186 miles per millisecond, which assuming you need to make a round trip in 20ms gives you an upper distance of ~1900 miles for live performance.
In reality however this will be much lower due to processing overhead, speed of light in fiber (~0.7e), and internet backbone topology.
Curious to know if the creators have done any tests, (or can show any demos) of the effective range this works at?
It's... complicated. What musicians can tolerate with practice and what will throw them off at first and muck them up is quite different. And there's the question of what you're playing - I can play slow stuff with terrible latency and it's fine, but start to play quick and you really feel it. It also depends on the instrument, it's a lot weirder playing something where the haptic feedback is off from what you expect on that instrument (or missing).
But in general, 20ms is considered the top end of fine. A good player can totally feel the difference between 10 and 20 though. Under 10 is not really an issue. After that, you have some stuff to get used to and while you might be able to jam, it's affecting you.
But in general, 20ms is considered the top end of fine. A good player can totally feel the difference between 10 and 20 though. Under 10 is not really an issue. After that, you have some stuff to get used to and while you might be able to jam, it's affecting you.
There's a whitepaper on the website. Short answer: they don't care
> There are a lot of people arguing that online jamming does not work because the overall delay is too high. They claim that latencies above 10 ms are not acceptable. In Jamulus typical overall delays are in the range of 30 to 70 ms. It is also typical that audio dropouts occur frequently (usually every 2 to 10 seconds per audible pop/interrupt sound). It has been our experience that, if the audio dropouts are not occurring too often, they are not perceived if the band members concentrate on their playing. If one focuses on the dropouts (and this is what people usually do when they try out the software) it feels annoying.
> There are a lot of people arguing that online jamming does not work because the overall delay is too high. They claim that latencies above 10 ms are not acceptable. In Jamulus typical overall delays are in the range of 30 to 70 ms. It is also typical that audio dropouts occur frequently (usually every 2 to 10 seconds per audible pop/interrupt sound). It has been our experience that, if the audio dropouts are not occurring too often, they are not perceived if the band members concentrate on their playing. If one focuses on the dropouts (and this is what people usually do when they try out the software) it feels annoying.
Latency is a lot lower than people generally think it is. I'm currently on a terrible satellite connection (not the popular one), and the latency to ping 1.1.1.1 averages 16.184ms right now, during awful weather, and never hits above 25ms. Probably the worst modern case scenario you could imagine for latency's sake, and significantly worse than I had ten years ago. In better weather, it's half that.
If you pull a few tricks, it wouldn't be anywhere near impossible to manage sub-20ms latency on your average connection. Now, over a web browser? I couldn't tell you. I wouldn't bet on it. But definitely possible natively.
If you pull a few tricks, it wouldn't be anywhere near impossible to manage sub-20ms latency on your average connection. Now, over a web browser? I couldn't tell you. I wouldn't bet on it. But definitely possible natively.
And people don't realize how "high" latency is for sound in air. 3ms per meter. Sound is 400,000 times slower per distance. Someone 10 feet away in your living room has the same latency as someone about 750 miles from you via magic network pixies (ignoring routing/switching delays, and the latency of each computer at either end going from bits into the network card, to electrical signal changes out the sound jack.)
In your case, 25ms network latency is equivalent to being 8 meters from another musician. That's basically "the other side of a medium-ish room."
It is funny seeing HNers so incredulous that something like this would work, when apparently lots of musicians have been using stuff like this for over a year, without issue. I wish more HNers realized that being smart isn't about knowing things. It's about knowing what you know, and understanding things like biases.
"Well, my knee-jerk reaction is that latency would be a problem. But I'm not a musician and I have no experience here. And clearly a bunch of people put a fair amount of effort into this. Let me see if my knee-jerk reaction is correct by either waiting to seeing what people who have actually used it say, or doing out the math to compare typical network latency to sound-in-air delay."
That's what a smart person says to themselves.
A smart person does not say, "This couldn't possibly be practical, I'm going to comment immediately to that effect."
In your case, 25ms network latency is equivalent to being 8 meters from another musician. That's basically "the other side of a medium-ish room."
It is funny seeing HNers so incredulous that something like this would work, when apparently lots of musicians have been using stuff like this for over a year, without issue. I wish more HNers realized that being smart isn't about knowing things. It's about knowing what you know, and understanding things like biases.
"Well, my knee-jerk reaction is that latency would be a problem. But I'm not a musician and I have no experience here. And clearly a bunch of people put a fair amount of effort into this. Let me see if my knee-jerk reaction is correct by either waiting to seeing what people who have actually used it say, or doing out the math to compare typical network latency to sound-in-air delay."
That's what a smart person says to themselves.
A smart person does not say, "This couldn't possibly be practical, I'm going to comment immediately to that effect."
I think we have enough smart people that are also musicians on here.
> I'm currently on a terrible satellite connection (not the popular one), and the latency to ping 1.1.1.1 averages 16.184ms right now, during awful weather, and never hits above 25ms.
1.1.1.1 is anycasted to many points of presence, one of which might be in the same state as you, so this data point is somewhat irrelevant. I'd be more interested in seeing what king of latency & packet loss you experience to another residential connection far from your location.
1.1.1.1 is anycasted to many points of presence, one of which might be in the same state as you, so this data point is somewhat irrelevant. I'd be more interested in seeing what king of latency & packet loss you experience to another residential connection far from your location.
Your objection is taking my comment in the least-intelligent light. There's no reason for this service to be P2P; MITMing the connection with a selective forwarding unit would work fine and is the natural conclusion one should reach when analyzing this problem. Cloudflare-in-the-middle would work perfectly.
Like any modern video game, or half of the decent video chat options in the world.
Like any modern video game, or half of the decent video chat options in the world.
By following the setup guide I was able to achieve 30-60ms latency. It's still a lot of fun. I spent a lot of time playing with others during the pandemic. A few tips for better experience:
- Mute participants that have high delay.
- Avoid rooms with more than ~10 participants.
- Mute yourself if you are not playing.
- Adjust your volume properly. If you are too loud, others may hear clicks and may perceive it as audio drops.
So far in the comments only worries about latency.
I had the same worries when my father told me about Jamulous and that his band started using it during the pandemic. They are a cajun band and mostly jam and they were singing the softwares praises and have used it for all practice leading up to the real life perfomances they've had the last few weekends.
It seems it's not actually a big issue, at least over a distance of about 300 miles.
I had the same worries when my father told me about Jamulous and that his band started using it during the pandemic. They are a cajun band and mostly jam and they were singing the softwares praises and have used it for all practice leading up to the real life perfomances they've had the last few weekends.
It seems it's not actually a big issue, at least over a distance of about 300 miles.
Light is not fast enough to do this for real... Do they have a new UI trick that is good enough to be fun?
Our business is virtual live music. We have tried everything - Jamulus, JamKazam, various plugins for Ableton, Protools, Logic, etc. Bottom line is speed of light = speed of light.
Good musicians can adapt to low-latency group playback, but it's difficult, and at that point, it isn't true realtime collaboration. The band/musicians are more focused on staying in time and fighting the latency versus really listening to each other and being a band.
One great tool for doing long-distance collaboration is Endlesss. (yes, three "s"s). Loop-based work that allows for real collaboration, and getting around the latency issue.
Good musicians can adapt to low-latency group playback, but it's difficult, and at that point, it isn't true realtime collaboration. The band/musicians are more focused on staying in time and fighting the latency versus really listening to each other and being a band.
One great tool for doing long-distance collaboration is Endlesss. (yes, three "s"s). Loop-based work that allows for real collaboration, and getting around the latency issue.
Endlesss.fm is the way to go for playing music with friends online for free.
Instead of trying to beat network latency (which is impossible) endlesss provides a shared looper and a clock to sync all your gear to. This way you can jam with people with zero audible latency, building up ideas. And a bonus is that every version (“riff”) is stored and can be revisited or exported into a DAW. It’s an incredible tool.
Instead of trying to beat network latency (which is impossible) endlesss provides a shared looper and a clock to sync all your gear to. This way you can jam with people with zero audible latency, building up ideas. And a bonus is that every version (“riff”) is stored and can be revisited or exported into a DAW. It’s an incredible tool.
For those who didn't take the bit of time to read the case study linked on the homepage of the OP, it answers the obvious question of "well isn't latency a problem?". It's well written and lays out some neat ideas.
For those who are too lazy -- TL;DR:
The software allows players to set up servers easily so if a band is geographically close, but remotely dialing in, latency is reduced. The software is intended to be used as the primary method of sound feedback so it's advised that amps are turned off and earplugs/headphones are used to block out "local" sound. And finally, the author of the case study found that their experience with latency was between 30-70ms and that was more than acceptable. The only problem stemming from this latency was that songs with fast drum fills needed some adjustments to slow down the drum fills.
For those who are too lazy -- TL;DR:
The software allows players to set up servers easily so if a band is geographically close, but remotely dialing in, latency is reduced. The software is intended to be used as the primary method of sound feedback so it's advised that amps are turned off and earplugs/headphones are used to block out "local" sound. And finally, the author of the case study found that their experience with latency was between 30-70ms and that was more than acceptable. The only problem stemming from this latency was that songs with fast drum fills needed some adjustments to slow down the drum fills.
So now that the tech exists, where is the service that helps matching different people who want to jam?
In the past 4 months, I got to know over 30 people by jamming with them on Jamulus. When you click on the "Connect" button Jamulus will list the public servers, sorted by latency. It will also list the name of people in each server. This works pretty well if there are Jamulus users in your area.
8 months ago, before Jamulus became more popular in my area, we used Clubhouse to connect with more musicians. We started a Clubhouse room and streamed the sound from Jamulus to that room. We put the server IP address in the room title and in the bio so listeners can connect to our server and jam with us. This brought our group from 3 people to about 20 people.
8 months ago, before Jamulus became more popular in my area, we used Clubhouse to connect with more musicians. We started a Clubhouse room and streamed the sound from Jamulus to that room. We put the server IP address in the room title and in the bio so listeners can connect to our server and jam with us. This brought our group from 3 people to about 20 people.
There's no way latency over the internet would be low enough to jam together... The latency of normal local computer soundcards without ASIO is too high for jamming. Anything above 10ms is noticeable.
Not true. It works. After some brain adaption. Then it’s fun. And what is jamming about? Fun! Not recording the next chart breaker.
And yet... thousands of people (including me) are doing it regularly.
No, it's not perfect but c'est la vie as they say
No, it's not perfect but c'est la vie as they say
People have been trying this for over 20 years, the first one I knew about was a Dutch company piping (IIRC) MIDI across the globe with a Shoutcast-style client app. "DragonNet" or something.
i was thinking that maybe a different approach with regard to latency could be tried... after all, these are not trades that need to reach a central server.
Rather than reduce latency, why not increase latency so that for the participant with the worst bandwidth, it can be delayed 1 sec, for the one with the best, it is delayed so that it syncs with the other person.
For a period of time when all participants have clicked that they are ready, real time is suspended, and some kind of calculation is made that will the voices in sync.
Rather than reduce latency, why not increase latency so that for the participant with the worst bandwidth, it can be delayed 1 sec, for the one with the best, it is delayed so that it syncs with the other person.
For a period of time when all participants have clicked that they are ready, real time is suspended, and some kind of calculation is made that will the voices in sync.
I think maybe https://echo.jefftk.com is what you're looking for? Also open source.
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.