Live remote 'jamming'

[Thunderbass1]

Has anyone had any success with live remote collaboration? I accept there will some latency but some sites imply that it can be manageable.
Jamkazam can be downloaded and it's set-up seems clever but it's internal links give 404 errors. Sofasessions actual site appears to be dead. I've yet to try Jammr.
Are there any other sites that anyone has managed to get working?

[alasdair thompson]

Hi, ive used Jamkazam ( in Midlands, UK) , basically a lot of tinkering with Asio settings, to speak with people round the world saying " how do i get this to work..). out of 10 sessions only once worked well enough to play, dont know where the server i, but all players in same city in UK..

Tried Jamulus, much simpler and ran server from spare PC, worked much faster, there is delay but nothing like I had using Jamkazam. Also noted that when not using private server and using server in London ( theres a choice of servers when you log in) was even then much better than jamkazam.

Suggest you try Jamulus, the documentation is generally good, and see if you can live with slap back echo effect of online playing..

Do bear in mind don't use WI FI, and if you do run a server from home you have to open port on router, so do use a PC for that only ( not online banking etc..)

Cheers,

Al

[DC-Choppah]

I am getting ready to try Jamulus. It is freeware and is similar to setting up a virtual LAN for gaming, but specialized for audio.

http://llcon.sourceforge.net/

Everyone must have an audio interface it appears.

This is a timely topic. I've got a bunch of jazz musicians asking how to do this. If we can figure this out it will make many musicians happy to be able to play together again.

Only try this with people close by (same town). Going far over the internet won't work. Speed of light.

[Jorge]

Yeah, I don't see how you could get around the latency issue to jam in real time. The latency of internet connections can be in the range of 700 ms, which obviously wouldn't work. Even the irreducible latency due to speed of light would be over 30 ms round trip if I in New York were to jam with a group of you in the UK and we went analog, skipped the internet and used a hard wired 3000 mile copper cable across the Atlantic. That 30 ms is still too long to jam and that does not include the internet latency or any AD/DA or CPU processing latency, all of which would be added on even if I were jamming with my next door neighbor over the internet. Of course we could lay down a track at a time, then send the file back over the internet, but that would kill the spontaneity of communication and the fun of playing improvisational music.

[ConcertinaChap]

I've read suggestions that JamKazam is using UDP (User Datagram Protocol) rather than TCP packets. Unlike TCP UDP prioritises speed of transmission over accuracy and is designed not to mind a few lost packets. I can see how this might allow a reduction in latency and the odd lost packet shouldn't affect music too much but the problem with JamKazam is it is apparently difficult to set up and the site itself is moribund. It's not something I find I can recommend to non-techies at present. YMMV, as they say.

AIUI NinJam, produced by Cockos (the Reaper people) works differently by increasing latency in order to make it correspond to bar lines in the improvised sequence. Thus the music you play along with was actually played one bar earlier.

I am getting ready to try Jamulus. It is freeware and is similar to setting up a virtual LAN for gaming, but specialized for audio.

I'd be very interested to hear how you get on with this.

CC

[CS70]

It doesn't really help much. Using UDP is what all video/audio software available already do. You have no ack packets and the packet header is simpler to process (no biggie has it's done in hardware anyways) so there's no ack waiting or window size. But on the other side you don't have congestion control either, which in traffic conditions can and will make UDP actually slower than TCP (as anyone who's ever used skype or zoom in busy network conditions has experienced). And you still have packets switching and routing, so in traffic conditions the routing is not reliable.

A possible idea is to set up several TCP connections together and distribute the packets over them, but for real-time bidirectional communication purposes it's still a bitch. IP is just not designed to do real time. You need point to point or spoke hub topology, not packet switching - and even then it works only within a limited geographical area. Physics is physics: you can't jam with someone on the moon (or even in high Earth orbit), no matter what.

Perhaps research in quantum entanglement might one day bring options here - after all, audio and video is pure information - but definitely not there yet.

With IP things might work (a little) on a private LAN, or on WANs which are topologically near and connected by a switch (and traffic under control). So with a purpose built ip network you could probably jam with your friends so long they are relatively nearby.

If you want to jam together, get yourself some radio equipment and you're much better off

[ConcertinaChap]

Thanks. That pretty much confirms what I thought. See you tonight, maybe?

The internal mechanism that Zoom uses to send its network messages handles two kinds of network packet: Transmission Control Protocol (TCP) and User Datagram Protocol (UDP).

UDP doesn’t have the kind of handshaking and packet loss prevention overhead that you find in TCP packets, making it leaner and better suited for the latency-sensitive network communications that you find in audio and video conferencing.

TCP is therefore typically used to control sessions, while the simpler UDP protocol is used to send session content.

CC

[Jorge]

What is the range of latencies for UDP?

[LarsenG]

Hello everybody, I managed last week to get stable 13ms roundtrip latency with a friend living in the same city as I am with a german software called "Soundjack", check it out at http://www.soundjack.eu. It works best when connected with Ethernet cable and you have to spend a little time to try the best setup (couple of paramaters, everything ist explained on the website), but it worked for me. It has also experimental video support too!

[CS70]

What is the range of latencies for UDP?

How long is a piece of string?
Latency is a property of the network. On an RFC1149 network (which was successfully tested almost 20 years ago right here in Norway) it probably averages from a couple of hours to a couple of days

[ConcertinaChap]

Certainly it's non-trivial when Zoom is using it.

Hello everybody, I managed last week to get stable 13ms roundtrip latency with a friend living in the same city as I am with a german software called "Soundjack", check it out at http://www.soundjack.eu

Thanks, I'll have a look. I'd dearly love to get enough performance for a band practice with our colleague in the next town. I'm not nursing hopes of worldwide sessions, I have to say.

CC

[DC-Choppah]

We are able to get Jamulus down to a few (2-3) msecs of latency with computers in the same house connected to the LAN.

I wanted to understand how to get rid of as much latency as I can on my end before going out to the WAN and introducing unknown latency sources.

If you use the public Jamulus server it automatically creates the port-forwarding in your network connection, but it will ask you to bypass your firewall to do that. This means anyone can see your room and jump in. This is a problem because random people seem to not realize that you have to use headphones! So they have a microphone and speakers set up and it generates feedback.

So to make a private server, you have to manually set the port forwarding in your router then give people the name of your server since they can't find it in the public server list.

So far the low latency comes down to having a good low latency audio interface and setting the buffer as low as it will go. The buffer is really the only thing that seems to be in play for the latency so far on the LAN.

You do not want to use ASIO4ALL or the microphone on the PC or your phone, etc. You do need to start with a good low latency audio interface with the buffers minimized and point Jamulus to that.

[DC-Choppah]

Well, going out onto the WAN, so far I can play with other people but the sound quality is really quite terrible. Sounds like playing through a bit crusher with dropouts.

We can get a 19-21 msec latency which the software says should be good to play. The buffer light is green and the delay light is green. Jamulus is setting the dither buffers automatically.

With the software as happy as I can get it, sound quality is very low-fi and kind-of garbled with spikes and dropouts and glitches regularly. Then sometimes, maybe 10 secs with no droupouts, then perhaps big droupouts. Always sound warbly, like a bad phone connection.

The professional jazzers I play with are not going to tolerate this sound quality and would walk away from it. Even in a pandemic.

You can't play anything detailed because the details are lost in the low fidelity. Then the dropouts happen and you just miss things.

This seems to be how low in fidelity the software has to set the sound quality in order to get the latency down.

The high fidelity sound we hear on Voip phones comes at the expense of delay if you have noticed. I see that they are recommending like .5 sec delays to get good quality Voip phone audio. That is the 'jitter buffer'.

So to get down to the 20 msecs latency, some serious sacrifice in audio is happening in the software. This makes the sound really just too inferior to play and do much musically with.

We are on fiber optic broadband internet (Verizon Fios) with all wired connections.

Here is an audio sample. My kids play piano while I record what you would hear if you were monitoring the jam session. The server is about 8 miles distant. Latency is 20 msecs. All the lights are green.

https://drive.google.com/open?id=1p8oBf ... 8zN4ynV5wq

Now imagine that with 5-6 musicians, so the audio drops out on all of them randomly. So someone is always dropping out or glitching. It is very hard to play this way.

I agree with what others have said. The internet is simply not able to do real time transmission. Good quality comes at the expense of latency through the jitter buffers that reconstruct the audio after the packets have been lost or delayed. You can't have both quality and low latency. There is no sweet spot in the middle where they are both good.

Perhaps this is why these server rooms are a ghost town.

[Drew Stephenson]

Thanks for doing all that testing and sharing the results.
Shame it's not what we were hoping for.

[Sam Spoons]

Still not going to work for jamming but this vid suggests a method of running online collaborations with decent sound quality. https://www.youtube.com/watch?v=OmJUOkf0kE4&fbclid=IwAR0yS3tUJbA0kGDwpQSDXs6yW04NAuUSM9XrJX7teYMgwZkqC5hpEK1Q_vQ

[CS70]

I agree with what others have said. The internet is simply not able to do real time transmission. Good quality comes at the expense of latency through the jitter buffers that reconstruct the audio after the packets have been lost or delayed. You can't have both quality and low latency. There is no sweet spot in the middle where they are both good.

Yeah, on a LAN it works because it's probably a "modern" switched ethernet or a simple one (everything on the same bus) but with only a couple of computers and very low traffic, so very little frame collisions. In that case, UDP will work very well for the same reasons you can go 250Km/h in an empty motorway in lockdown times: it's a straight line and empty, there's nothing to crash into.

The moment you introduce traffic and routing you can't get even remotely near these speeds.

The old modem PPP protocol between two modems over a switched telephone line (not tunneling into an IP network) might work better - at least to jam in two.. too bad nobody uses modems anymore and the quality would be probably still pretty bad.

[DC-Choppah]

Still not going to work for jamming but this vid suggests a method of running online collaborations with decent sound quality. https://www.youtube.com/watch?v=OmJUOkf0kE4&fbclid=IwAR0yS3tUJbA0kGDwpQSDXs6yW04NAuUSM9XrJX7teYMgwZkqC5hpEK1Q_vQ

Right. 100 msec latency and good audio quality (16 bit PCM). Perhaps that is the sweet spot.

Will probably generate glitches and dropouts in some network conditions, leading to the need for higher latency settings (500 msecs) - like in Voip phones.

You can't jam. But you can track one remote source. So then why not just set the latency higher (500 msecs)? There is really no reason to try to force the latency low if you just are recording one source to a cue mix. Latency is not important.

Folks on the other end still have to set up their recording equipment to track. But this approach to remote tracking could make it more like a recording session for the artist.

A better approach though to remote tracking might be to simply take remote control of the clients PC and tracking software? Audacity, and a small audio interface is all they need for a tracking session. If they can be instructed to set it up, we could just take control remotely.

I like the idea of remote tracking for musicians that are not technical. That would be very useful to me in these times.

[Sam Spoons]

I'm in the process of setting up a recording session with my bass player (and best buddy) while we're both locked in. We don't write really so now seems a good time to start. For a start I've got him to download Reaper and set up a shared dropbox folder 'cos we both understand dropbox, I've just put a simple project in the dropbox to get things working. Will probably FaceTime on iPads for the comms side to start with.

[Drew Stephenson]

For remote tracking this is worth a read: https://www.soundonsound.com/techniques ... production

[jimjazzdad]

I am surprised that there is no mention of Ninjam, the Cockos jamming collaboration solution. No latency, as its based on everybody entering on a beat, essentially a click track, so its not actually real-time but everyone is playing in-time. I am not a musician, so I cannot comment on how easy it is to play that way, but the youtube videos make it look like fun and the audio quality is reasonable (Ogg vobis is the compression engine, I believe).
EDIT: I should mention that it is a Reaper plug-in...not sure if it works with other DAWs

[DC-Choppah]

For remote tracking this is worth a read: https://www.soundonsound.com/techniques ... production

That's great, and gives the links to the free software needed. I like the remote control of the client DAW.

I am thinking of a package that could be easily shipped. Includes everything the client needs. Simple instructions. They set it up. We take control, and they just play music. Then repackage and send it along.

Please understand we deal with people who don't have the recording equipment at home or the funds, or know how to buy and set this stuff up. Yet, they can play their hearts out!

[Sam Spoons]

They will still need recording hardware of some kind and a reasonable sounding space if using mics so a certain level of commitment from them will be necessary but that and the stuff in the vid I linked are certainly a huge improvement on what was available a few years ago.

[awjoe]

...and a reasonable sounding space if using mics...

^ This. I've heard a lot of really sketchy recordings since people starting communicating from home recently. I've heard it on CBC often enough to suspect that it's a sort of 'signature sound' intended to indicate that the speaker is operating out of their sitting room. No, scratch that. It's just CBC being incompetent.

[ConcertinaChap]

I am surprised that there is no mention of Ninjam, the Cockos jamming collaboration solution.

I had mentioned this. It's an interesting idea in that rather than trying to avoid or remove latency it seeks to use it in a creative way. What it cannot do is what everyone else wants to do which is play with others over the internet as if we were all in the same room.

CC

[DC-Choppah]

They will still need recording hardware of some kind and a reasonable sounding space if using mics so a certain level of commitment from them will be necessary but that and the stuff in the vid I linked are certainly a huge improvement on what was available a few years ago.

I am thinking that we put everything in the package:
- Computer
- Audio interface
- Microphone
- Mic stand
- Cables
- Instruction card