Live data from Hacker News

Show HN: Low-latency jamming over the internet

sub.live

91–100 of 124 posts

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

#91

Earlier quoted context omitted.

Why does fiber have lower latency to the exchange than copper? That surprises me. I thought that ISPs generally run fiber for most of the distance, and coax is only used for the last few hundred meters. The speed of signal propagation is actually faster in copper than fiber, but nobody (afaik?) does long runs over copper so it’s a moot point.

Yes the ISP runs fiber to the DSLAM or the CMTS, and copper is used for the final hop to your home. The latency comes from the buffering and processing required to get a clear signal over copper - for DSL I think you can get in a perfect scenario 7ms or so with fastpath, more if you use interleaving. For fiber you can pretty much treat it as like an Ethernet connection, with latency determined almost solely by distan…

Yup I remember fastpath, it's a choice of low latency vs higher bandwidth. I'm not sure if ISPs still actually bother offering this option to end users anymore though? I mean it's all turned into scripted tier 1 support nonsense if you call an ISP these days.

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

#92

Earlier quoted context omitted.

Why does fiber have lower latency to the exchange than copper? That surprises me. I thought that ISPs generally run fiber for most of the distance, and coax is only used for the last few hundred meters. The speed of signal propagation is actually faster in copper than fiber, but nobody (afaik?) does long runs over copper so it’s a moot point.

Yes the ISP runs fiber to the DSLAM or the CMTS, and copper is used for the final hop to your home. The latency comes from the buffering and processing required to get a clear signal over copper - for DSL I think you can get in a perfect scenario 7ms or so with fastpath, more if you use interleaving. For fiber you can pretty much treat it as like an Ethernet connection, with latency determined almost solely by distan…

Ahhhh interesting - so the latency comes from the noise in copper, which forces you to do extra work, which adds latency per bit? That makes sense - thanks!

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

#93
post #86

I may be missing something but this appears to me to be a WebRTC application. It is very easy to build something like this using any modern browser's WebRTC APIs, just disable audio processing in the media constraints and munge the opus SDP to stereo, maybe play with the network buffer setting if you want to lower latency but the audio hardware and physical distance is going matter more there. The developer states th…

It uses WebRTC for the video, but the audio latency of WebRTC is too large and uncontrollable.

As stated in the post, the audio uses a custom C++ UDP solution. As far as I know it's the first video calling app with very low latency audio.

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

#94

Wow. I really like the positioning of your product: the audience and value proposition are crystal clear. I'm going to share this with my musician friends and see what they have to say. I know they had challenges jamming at the start of the pandemic lockdown that stemmed from a) variance in internet connection strengths and b) innate latency in Zoom. All the best & kudos for launching!

Thanks !

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

#95
post #52

I'm very interested in this! Can you say how this compares to something like https://jamkazam.com ? One of my issues with JK is that it seems to require all participants to be members, and to pay for relatively pricy memberships to partcipate. I'm sympathetic that nothing is free and I'm willing to pay for a good service, but I'd love to have a model where one person could pay for a session that others could join (wi…

I would like to make some money with it to continue the support, but it's not clear yet the best way forward. Currently it's donationware, but other models could be a subscription, or some sort of premium/freemium model.

Really I just want to see how people use it and figure it out from there.

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

#96
post #83

This is super cool. I’ve been formulating a similar idea for a while now. I’m building a desktop utility for guitarists using clojurescript and Tauri. I also wonder if this can also capture ASIO audio streams in a useful way? My goal was to do something like that to allow streaming of processed audio. Some differences in what I was planning and accompanying thoughts: Clojurescript. I do like that it’s using Svelte, I…

Thanks!

I haven't ruled out opensourcing, but honestly I already have limited time and in my experience open source takes _more_ time commitment (I get that you will get free help eventually).

I'm making a VST plugin to stream output from a DAW.

Problem with Tauri is that you have to support the native browser, rather than just chrome, so it's more work to build and maintain.

Good luck with your project!

J

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

#97
post #91

Earlier quoted context omitted.

Yes the ISP runs fiber to the DSLAM or the CMTS, and copper is used for the final hop to your home. The latency comes from the buffering and processing required to get a clear signal over copper - for DSL I think you can get in a perfect scenario 7ms or so with fastpath, more if you use interleaving. For fiber you can pretty much treat it as like an Ethernet connection, with latency determined almost solely by distan…

Yup I remember fastpath, it's a choice of low latency vs higher bandwidth. I'm not sure if ISPs still actually bother offering this option to end users anymore though? I mean it's all turned into scripted tier 1 support nonsense if you call an ISP these days.

I had to specifically ask for fastpath for my DSL connection, without it I get around 35ms to the exchange. You however do need a decent connection to the DSLAM for it to work properly without packet loss. You can get the same bandwidth over fastpath as interleaving if the line is clean.

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

#98
post #73

Earlier quoted context omitted.

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 re…

Well you do need to find a server midway between all the users, which is a hassle of course. I don't personally like the model either becuase it needs to decompress, mix and recomopress all the streams on the server and also needs an extra jitter buffer. The only clear benefit to it AFAIK is that it scales better for larger groups O(N) rather than O(N2)

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

#99
post #71

Earlier quoted context omitted.

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.

Yes JUCE is da bomb

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

#100

Earlier quoted context omitted.

Ah, that's interesting. I'm using a USB audio interface. It claims to be ASIO compatible. Oddly enough I tried the same interface in different computers, and have tried other computers, but haven't dug much further than that. I've also tried all of this on a decent Ubuntu box, and I've now got it running on a Raspberry Pi 3 since the overall latency has been more less the same in all cases. We're all analog musicians…

You need to switch the drivers from WDM to ASIO. Most DAWs have this as an explicit choice with WDM as the default.

I think WASAPI has comparable latency to ASIO drivers. I can get around 20-30ms latency with WASAPI though ASIO takes me down to 10-15. Granted I'm using a dedicated USB audio interface though.
Post reply on HN