The important number is round-trip latency, and we found that around 25ms is good enough (we're all quite used to playing with people of varying time-keeping ability anyway). I think there's scope to improve on that using a library like Roc (https://github.com/roc-project/roc) where you can target a specific latency. I've been meaning to play around with it, but to be honest I'd rather be playing music :)
We see that too: 25ms one-way latency is the max to stay in sync, and that includes both internet + audio device encode/decode, which gets eaten up quite fast!
We are looking at providing an optional premium networking service to offer a faster connection as an alternative to the open internet. Nothing too expensive, like $10/month is the goal. Hope that gets you and your friends under that magic threshold when it's available, if you try it out.
Since you're here, I'll ping you some feedback:
- The UX is, charitably, idiosyncratic. We all found it hellaciously difficult to get started, find each other, start a session that didn't have strangers popping into it, manage audio (more on that below). The UI is honestly just super crazy insanely weird.
- The audio handling is... counterintuitive too. I expect to be able to control my "monitor" mix, and have one person control the master mix. But that just isn't working. Instead of one channel strip per source, we just each see a single fader for each participant (even though each person has vocal mic and instrument mic) and it seems to affect everyone globally.
- Everyone slows down over the course of the song. We're all listening to each other, so the latency builds, and we all end up dragging horribly. Only solution we found was to have the drummer play to a click which is miserable in our genre and generally not fun outside of a studio session (which is "work" anyway).
I _really_ hope you're able to use some of the newfound interest you've got to inject some new life into the service. The core is so promising. Notwithstanding that feedback, I'd pay $10/mo for a non-social private version where I can host my own server, since all my bandmates are within a mile of me.
Unfortunately I might not be in many sessions for a while as I replaced my last Windows machine with Linux this weekend, which I don't think you support yet; although I will have a go at getting it working in WINE :)
Do you plan to work on Linux support?
We need to take that section/link down.
We did do a KickStarter for the JamBlaster, made ~200 and shipped them.
But we are not in a position to be focusing on custom hardware.
... a dedicated device is half the puzzle. That, and a low-latency network connection to your peers. You have those two and you can get a reliable experience.
I don't know at what point the scaling breaks down.
So we have these pretty ordinary situations where there's about thirty milliseconds of latency between when a drumstick strikes a head and a guitar player hears it. Of course, in a modern live pop performance there's all the crazy monitoring and latency compensation to try to make a football stadium acoustically comprehensible, but there is still the physical reality of how people normally play music together.
If I ping google.com from my house, on my crummy wifi, right now I'm getting about 10ms. This is roughtly the latency a guitar player experiences standing at the end of a 10 foot cord from their amp between their pick plucking a string and the resulting sound striking their eardrums.
Reality has latency.
“Jamming” is much more dynamic, and uses a combination of audio and visual cues to work.
The problem with even fantastic network latency in the 10ms range is this gets multiplied by the number of participants, and quickly turns into a shitshow.
The only approach I’ve seen that even sorta works is the approach ninjam took with a hard coded and pre determined latency. It’s not the same as a real improv session with real humans in the room, and has obvious limitations, but can at least give a little of the same experience without the uncanny valley.
But even with zero auditory latency, musicians (classical musicians at least) don't really use sound to synchronize, because the cue must come before the sound is made.
That's why in any competent orchestra, musicians rely on visual synchronization. For example, the string sections look at the concert master, who in turn communicate with the conductor and the soloist.
In chamber music, the musicians constantly look, nod, and body gesture at each other to synchronize.
The internet is competing with light not sound.
Musicians in an orchestra pit or on a football field visually synchronize to a shared clock -- the conductor visibly keeping time. In a live setting, musicians use monitors (in-ear or wedges) that zip the sound of their bandmates to them via the speed of light.
I've never seen virtual jamming over a network without a shared clock actually work, because once you get to 200ms round-trip it just doesn't work.
Your ISP and their ISP have a certain amount of delay or lag which can't be avoided, but it's possible to improve your delay on your own side of the cable / dsl / fiber modem by using Ethernet instead of Wifi. My Wifi router (a slightly older, last-model Apple unit) introduces about 10-12ms all by itself.
That impressed me about the low threshold of latency needed, if the distance of less than a hundred meters can be too much for sound to travel between players.
I'm hopeful that latency will continue to reduced, as much as technologically (and physically) possible. Real-time jamming over the wire will continue to improve.