Enable lowest OPUS framesize not only for <64 samples buffer.

[38github]

Is there a reason why the lowest OPUS framesize are not enabled when using other than <64 samples of latency buffer? I believe that being able to achieve the lowest delay even if you do not or can't use 64 samples is important to make the Jamulus experience as good as it can get.

These are the numbers I get when setting Jamulus' local
and server buffers to 1 and 1, enabling "Enable Small
Network Buffers" and excluding the ping time from the
delay value.

 64/2 =  8 ms delay (JACK reports  64/2 equals 1.3 ms)
128/2 = 16 ms delay (JACK reports 128/2 equals 2.7 ms)
256/2 = 26 ms delay (JACK reports 256/2 equals 5.3 ms)

This means that on top of the audio interface's
latencies:

 64/2 has  6.7 ms
128/2 has 13.3 ms
256/2 has 20.7 ms

Imagine if we instead could have these Jamulus delay
times:

 64/2 =  8 ms delay
128/2 =  9 ms delay
256/2 = 11 ms delay

Some of these numbers are approximates and/or rounded
up or down to a whole number.

If I am wrong, which I potentially might be, then
please correct me.

[pljones]

There are four sets of buffers:

• audio buffers
• network buffers ("Small network buffers" checkbox under the jitter buffers)
• the pair of jitter buffers

I'll skip the jitter buffers - they're in multiples of the network buffer size, as far as I'm aware but beyond that... I get a bit lost.

It's down to the client to pick the audio buffer size most appropriate to their system capabilities.

The server has to coordinate clients using network buffers of either 64 or 128 samples. Basically, it takes two 64 sample buffers from a client using that size buffer to queue to all clients using 128 sample buffers and sends 64 sample buffers as soon as it can to clients using them.

Say network buffers of 32 samples were introduced. The server would collect four such buffers from a client using that buffer size before queuing for mixing with other clients. The mix for that client would then be a 128 sample block sent as four 32 sample buffers. So there wouldn't be any time saving within the server.

So whilst the mix from the server would start to arrive sooner, it wouldn't have left any sooner. (But with more codec and network overhead.)

The main point is that the server mixes in 128 sample blocks - nothing related to OPUS, just to keeping all clients in line and vaguely synchronised.

[pljones]

--fastupdate is required for Small Network Buffers to have any effect anyway. But it only affects clients with Small Network Buffers enabled -- the server has to cater for clients without. And the reason for that is the overheads are increased if you're creating more packets: some systems may work better without Small Network Buffers.

[38github]

Can't the server, if configured with --fastupdate, have it active for 64, 128 and 256 clients? If the server is slow or the internet connection is slow they just have to not configure it with --fastupdate? Even old $20 SoCs can handle up to ten clients using 64 samples and Enable Small Network Buffers.

[pljones]

Receiving and sending network packets is what --fastupdate and Small Network Buffers control. (And possibly the jitter buffer granularity.)

If you have 64 sample audio buffers and choose not to use small network buffers, you'll still see lower latency than when using larger audio buffers - but the latency will drop if you use small network buffers and you connect to a server with a high enough version configured with --fastupdate.

If you have audio buffers above 128 samples, small network buffers and --fastupdate won't have any effect. There's nothing the server can do about that.

We don't have any information about which clients are using the latest software but we know not all servers are.

So new clients need to support both old and new servers.

And new servers need to support a combination of old clients and new clients at the same time. To do that, they have to use a single sized buffer for the mix: that's the same size that's always been used - 128 samples.

To get the 128 samples with smaller network buffers, that means waiting for multiple incoming packets and queuing split buffers into smaller packets.

For "standard" network buffers, the mix buffer is loaded and queued directly from/to the network layer.

[dcorson-ticino-com]

Can't the server, if configured with --fastupdate, have it active for 64, 128 and 256 clients? If the server is slow or the internet connection is slow they just have to not configure it with --fastupdate? Even old $20 SoCs can handle up to ten clients using 64 samples and Enable Small Network Buffers.

That depends more on the Internet provider than your hardware. Two people I play with regularly are using latest Apple hardware and have much poorer sound (on the same -f supporting server) using small buffers that without. Figure it out.

[38github]

Then they have the option to disable -f. If I remember correctly it is not enabled by default either on client or server.

[jujudusud]

Wouldn't the main reason be that OPUS is only designed to use 128 samples buffers by default?

[pljones]

Getting into the codec itself is a different matter - that raises the question over whether a different codecs could be used where network latency allowed it. The resultant audio could be mixed anyway, with the existing codec remaining available.

[38github]

So, from the developers perspective, is this something that is possible to do?

[pljones]

It would need someone wanting to write the code. Do you want to?

[38github]

I am more interested at this point if it would be possible.

[pljones]

That would most depend on someone wanting to write the code. Without that, then no, it's never going to happen.