Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Low-latency jamming over the internet

sub.live

Post reply on HN
Print view View original

71–80 of 124 posts

Re: Show HN: Low-latency jamming over the internet

#71

Post by emerged »

capableweb wrote: post #13
emerged wrote: post #11

I had assumed this would be a VST plug-in so you could integrate everyone into (for example) an Ableton Live set with whatever other audio/midi manipulation you want.

Using audio devices directly makes it possible for any audio application to use it, not just applications supporting VSTs. Makes it more flexible, not less. A VST could be built on top of the current solution, but if it was done vice-versa, it wouldn't.

VST frameworks like JUCE export to VST or stand-alone. So you get both for free. Much easier and more flexible.

Also DAWs don’t typically allow you to interface with multiple audio devices. There are ways of doing it but they have major downsides.

Re: Show HN: Low-latency jamming over the internet

#72

Post by __turbobrew__ »

rdtennent wrote: post #57

My experience with Jamulus might be instructive. Members of our group live in the same city (Kingston, Ontario) but use two ISPs. Packets between users on the same ISP were fine but packets from one ISP to the other were being routed via Toronto and then Chicago and ultimately back to Kingston. It's not the distance travelled that's the problem (speed of light), it's the latency introduced by each intermediate node.…

Something similar was happening in Calgary where multiple ISPs in Calgary peered through Seattle and Toronto. Luckily YYCIX was formed and it appears that things are much better now: https://yycix.ca/talks/cuug-2013-06-18/mgp00001.html

Re: Show HN: Low-latency jamming over the internet

#73

Post by weepy »

rdtennent wrote: post #57

My experience with Jamulus might be instructive. Members of our group live in the same city (Kingston, Ontario) but use two ISPs. Packets between users on the same ISP were fine but packets from one ISP to the other were being routed via Toronto and then Chicago and ultimately back to Kingston. It's not the distance travelled that's the problem (speed of light), it's the latency introduced by each intermediate node.…

The issue with Jamulus is that it requires a central server - which means it needs to be close to everywhere . It also needs double buffering and double compression. P2P is the way forward here IMHO.

Re: Show HN: Low-latency jamming over the internet

#74

Post by weepy »

fenesiistvan wrote: post #42
weepy wrote: post #19

Earlier quoted context omitted.

Yes Opus - the other benefit is that it can handle a degree of missing packets which is very handy.

And that feature adds ~20 msec more latency

You must have set it up wrong. It doesn't add any latency, but you do need a higher bitrate to get similar quality.

Re: Show HN: Low-latency jamming over the internet

#75

Post by wmwmwm »

k__ wrote: post #29
erinaceousjones wrote: post #24

Earlier quoted context omitted.

"This won't work with the commodity technology I use" (wireless LAN) "Here's some ways in which it can work using a slightly different but still as widely used commodity technology" (wired LAN) "No, that is unreasonable, wires are unreasonable" Like, it's SUCH a simple solution: use wires. That's how I can stream games from my computer to my parent's house at 1080p60 with only about 30ms latency over domestic broadba…

How is 30ms remotely a good latency here? I have 14ms between my Quest/PC and it feels sluggish.

It’s worth remembering that sound takes 3ms to travel a metre. If you’re standing a few metres away from a drummer then the round trip time is already pushing 20-30 ms of latency and yet you can still play together in a rehearsal room

Re: Show HN: Low-latency jamming over the internet

#78

Post by mgamache »

fouc wrote: post #77

Does anyone know of an alternative that keeps both audio & video in complete sync, but possibly pauses/buffers at times in order to maximize the segments where everything is kept in sync?

Not possible to be in complete sync and have ultra low latency. You would have to have a jitter buffer (at least).

Re: Show HN: Low-latency jamming over the internet

#79

Post by wmwmwm »

grepfru_it wrote: post #40
k__ wrote: post #33

Earlier quoted context omitted.

That's why I don't believe those numbers. All I've seen in shorter distances was usually worse :(

this right here. 1 mile away, both of us have AT&T fiber, we're seeing 10-15ms response times (packet size ~1400). 100 miles away, both on AT&T fiber clocked in around 18-20ms 1 mile away, one on AT&T fiber the other on Comcast gigabit had response times around 24ms 100 miles away, one on AT&T fiber the other on Comcast gigabit had response times around 35ms i'm hard pressed to believe you will find an american ISP t…

I see 3ms ping times between my friend and I on opposite sides of London, though we’re both on pretty decent broadband tech (me gfast, him some fancy hyperoptic plan). IIUC there are some ADSL technologies that add some minimum latency floor of 10+ ms. However the long distance stretches of backbone fibre shouldn’t necessarily add too much latency - e.g 100km of fibre at 2/3rd speed of light is an additional 1ms on your (two way) ping time

Re: Show HN: Low-latency jamming over the internet

#80

Post by rdtennent »

weepy wrote: post #73
rdtennent wrote: post #57

My experience with Jamulus might be instructive. Members of our group live in the same city (Kingston, Ontario) but use two ISPs. Packets between users on the same ISP were fine but packets from one ISP to the other were being routed via Toronto and then Chicago and ultimately back to Kingston. It's not the distance travelled that's the problem (speed of light), it's the latency introduced by each intermediate node.…

The issue with Jamulus is that it requires a central server - which means it needs to be close to everywhere . It also needs double buffering and double compression. P2P is the way forward here IMHO.

"requires a central server" is misleading. You can set up a server wherever; there's no central server. Except for the multiple-ISP issue I discussed, there's no reason access to a server is more latency than access between the "clients". The advantage of the server/client model is that the clients can be very lightweight: I personally use a Raspberry Pi 3 with an ultra-low latency DAC/ADC hat. Works fine. All the real computation is done on the server.
Post reply on HN