Show HN: Low-latency jamming over the internet • Hacker News Board

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

#121

Post by namibj » Mon, Oct 25, 2021, 5:20 PM UTC

adzm wrote: post #100

colossal wrote: post #90

Earlier quoted context omitted.

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.

You should be able to easily sustain below 5ms buffer size, and RT_PREEMPT Linux has no problems keeping a few hundred microseconds of buffer filled (a suitable PCIe soundcard should easily make 100us buffer level reliable; that's 9.6 samples at 96kHz sample rate).

Yes, sub-ms latency is hard. But the infrastructure exists.

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

#122

Post by weepy » Tue, Oct 26, 2021, 12:01 PM UTC

rdtennent wrote: post #116

weepy wrote: post #115

Earlier quoted context omitted.

P2P doesn't require any computation on any server - it's essentially serverless. It doesn't make much sense to me at least to need to compress everything twice and have multiple buffers AND have to manage a server.

Well if any of the O(N^2) connections has unacceptable latency, you'd understand why a server is sensible. Reducing computation won't improve latency in the connections. One has no flexibility with clients but a server can be located wherever good connections are available.

There is flexibility - in the P2P model if one of the clients has bad latency - their buffer gets increased to prevent drop outs. How is a server better in this scenario?

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

#123

Post by weepy » Tue, Oct 26, 2021, 12:02 PM UTC

rdtennent wrote: post #113

weepy wrote: 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.

> P2P is the way forward here IMHO. But if any of the O(N^2) P2P links has unacceptable latency, eliminating the server would be counter-productive because the client-to-server connection may have less latency if the server is located appropriately.

Maybe I'm missing something but A->B is likely to be faster than A->S->B ?

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

#124

Post by weepy » Tue, Oct 26, 2021, 12:03 PM UTC

digitallyfree wrote: post #97

tomxor wrote: post #91

Earlier quoted context omitted.

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.

woah what is this fastpast magic ?!