Buffer delay setting behaviour in Jamulus

[leoinlios]

Hi all, I set my Presonus Studio 24c interface ASIO driver to 16 samples:

But Jamulus overrides this driver-led setting and sets itself to 64, while letting me pick 64, 128 or 256, i.e. the Buffer Delay radios are ENABLED.

If I connect my TD-27 module (ASIO), Jamulus DISABLES the radios and 48 samples is the only choice.

This tells me that if the driver supports a sample lower than 64, Jamulus allows it, however, this is not the case with my Presonus interface driver.

Can someone please explain why sometimes Jamulus enforces/enables its 3 Buffer delay choices, while other times it let's the driver decide? By the way, I get better latency with the Interface at 64 than the TD-27 at 48 (which does not make sense to me), circa 5ms improvement in overall delay.

Thanks guys

[jujudusud]

You can't use another block size than 128 if you want to have a good result.
64 is a good choice if you are hosting the server in your local network.

[dcorson-ticino-com]

I don't know the answer to your question, it is apparently driver dependent.
On the other hand I use 64 sample buffers with small network buffers all the time and have great results, under Win10.
The small network buffer setting does need more bandwidth, but if you have the bandwidth why not use it if it gives you lower latency?
I have not noticed any of the problems that are sometimes attributed to the use of small network buffers.
I have the impression that Linux needs bigger buffers from what I read here, but don't understand why that should be.

[jujudusud]

@leoinlios :

To be clear, if I can currently get 24ms delay on 64 samples (per above picture) and do not have much jitter or other sound artefacts, why would I out of choice make changes to make the latency larger?
24 ms is the case when you are alone on a certain server. Would it be the same with 4 other musicians connected at the same time ?

So, ok, your set up is ok with this server + 64 samples + small network buffers. Fine, nice.
Now if you want to go with a lower latency, you should provide your own server on your local PC or on another one in the same local network. This would lower the ping time...

[rdica]

Note that small network buffers MUST be supported by the server. Its not a default. Most servers do NOT have this enabled.

[dcorson-ticino-com]

Note that small network buffers MUST be supported by the server. Its not a default. Most servers do NOT have this enabled.

The transfer protocol takes care of this. But if you don't turn it on you will not profit from the servers that do have it.

[jujudusud]

Did you try to use your own server on the same local network ?

[ghost]

Looking at the Studio 24c picture in the opening comment:

• Sample Rate = 48.0 KHz (good)
• Block Size = 16 (should be one of: 64, 128, 256 otherwise bad will happen)
• Input and Output Format: Jamulus uses 16 bit signed integer (similar to .wav)
  (Format conversions may add latency depending on where they are done.)

BTW, Jamulus alllowing a 48 block size looks like a bug.

[leoinlios]

Thanks @pljones - you have stated that if the buffer is set to less than 64 samples, there is no reduction in latency.

Please can you explain this then:

1. Buffer set to 64 - (Presonus driver) - Buffer delay 2.67ms - Server overal delay 31ms
   

2. Buffer set to 16 - (Jack) - Buffer delay 0.67ms - Server overall delay 24ms
   

Measures taken on the same server (not my server). All settings matched. Ping matched. Clearly setting the buffer to lower than 64 has caused a reduction of latency, did it not? Or are you saying Jamulus has a bug and is incorrectly reporting the delay in the second case?

[pljones]

The jitter buffers have changed size. Turn off auto and compare again...

Hm...

I have to say, I don't understand how the overall delay figure related to the network buffer size, the audio buffer size and the jitter buffer sizes -- I can't make the numbers work with a quick check and I've not looked at that code...

[pljones]

Couple of quick examples here

This is my Linux server running Jamulus client connected to one of the local Jamulus servers. JACK is running with the dummy audio driver. Both Local and Server jitter buffers are 2 and I get a delay of 10ms with audio and network buffer sizes of 64 samples.

Here I'm connecting over the LAN, Jamulus using ReaRoute to Reaper, Reaper using my Echo ASIO driver, 64 sample audio and network buffers. Jitter buffer settled to 2 each way eventually but the ping is bouncing from 0 to 2, rather than a steady 0. But still about the same.

Turning off Enable small network buffers doubles the overall delay from about 10 to about 20 - the jitter buffer sizes didn't change, but each buffer is now twice the size, so the delay doubled.

So, here's ASIO4ALL with 64 samples. Again, pretty similar overall delay. However... the Local jitter buffer size is 4...

So I'm not sure if both sets count. Maybe only the Server jitter buffer counts towards the delay figure. Let's see... No, if I turn off manual and set Local to 1 and Server to 9, it has the same effect on the delay as if I set Local to 9 and Server to 1. Similarly with 10/10 vs 1/19 and 19/1.

I'm running here either on a local server or over the LAN to the server, not over an external network connection. So let's try that next.

This is a server over in the US somewhere, I'm in the UK, so the ~100ms ping is normal. The additional delay of ~14ms looks okay, too. Jitter buffers are at 4 and 5. This is dummy audio JACK for the "normative" test.

So this is with ASIO4ALL again. Roughly the same size jitter buffers (6 and 4 now) and similar additional delay over the ping.

And with Jamulus into Reaper/ReaRoute

---

So.... next, let's try a local connection with the jitter buffers in your 10ms ping / 31ms delay example:

I get the same additional delay from the jitter buffer. So it looks like the 2ms ping plus jitter buffers = 22ms delay.

And with jitter buffers set to 6 and 4 like your 10 / 24 example, I get 0ms ping and 15ms delay. Again, that's the same.

Definitely looks like it's all down to the jitter buffers and nothing to do with the audio set up.

[pljones]

I also noticed something with my Echo driver. The lowest buffer size is 64 samples and at that the lowest delay Reaper claims is 4ms. Doubling the buffer size to 128... adds 1.3ms. So the extra 64 samples adds 1.3ms, which makes sense. But it's also fairly clear that either the device driver or the hardware itself are doing additional buffering -- and that the device driver is reporting that to Reaper.

If you take that final 64 samples of ASIO buffer size off the 4ms, you get 2.7ms. Halve that you get 1.35ms. So two lots of 64ms.

Now, I find it hard to believe that any hardware connects with no buffering, so I'd expect to see a certain additional amount beyond ASIO buffer size being reported by the hardware's ASIO driver, if it's reporting correctly.

[roshank8s]

There are two different pairs of buffers, so four buffers, to consider:

• audio input to Jamulus
• network output from Jamulus
• network input to Jamulus
• audio output from Jamulus

The audio and network buffer size do not have to be the same size. Audio will be read from the audio input until a network buffer is filled, which will then be inserted into the jitter buffer queue before despatch. Similarly, incoming network packets go into the incoming jitter buffer queue before being written out to the audio buffer.

If there is a buffer size mismatch, either multiple audio buffers are needed to fill a network buffer or multiple network buffers are needed to transport an audio buffer. The "ideal match" is 128 samples for both. If CPU and network bandwidth are not constraints, 64 samples for both is fine.

On send, if your audio buffer is lower than 64 samples, Jamulus will wait until the last of 64 samples is read before sending the audio, so there is no reduction of latency within Jamulus.

On receipt, if you set the audio buffer smaller than 64 samples, the last of those 64 samples gets processed by your sound card no sooner than if your audio buffer size was the same as the 64 samples, so there is no reducation of latency within Jamulus.

There are only two network buffer sizes - 64 (which came in during 2020, I think?) and 128 (which has been around "forever").

It's up to the audio device driver to let Jamulus know whether Jamulus is allowed to set the buffer size - not all drivers do. If the controls are greyed out, then Jamulus has no control. (Reaper, as another example, always allows the user to decide to "try asking the driver to set it" -- but the driver can still refuse, so you still have to read the actual buffer size setting from the driver.)

@pljones Can you please explain more - The audio and network buffer size do not have to be the same size.
and where i can set or verify network and audio buffer size settings.

[leoinlios]

I think these below show the case in point that whether you set the buffer size to 64 or less, as long as the jitter settings are the same, the latency will NOT be improved with a lower buffer size.

First: local server, ASIO driver, 48 samples (we see Jamulus buffer options disabled as the driver is taking over buffer size management it seems).

Second: local server, ASIO driver, 64 samples (we see Jamulus buffer options enabled).

Same server, same jitter sizes, same instrument, same driver, same delay results, which confirms your point (@pljones ) about anything less than 64 samples not improving latency.

[leoinlios]

I just opened Jamulus Server, made it not public, connected to it, no other changes. I wouldn't even know where to look for the local server settings you are asking. Where would that be set?

[jujudusud]

Here are some informations :
https://jamulus.io/wiki/Running-a-Server

[leoinlios]

To answer your question, I have run the server using the server GUI, so whatever defaults it uses. I have not used command line options at all.

[jujudusud]

Take a look at fastupdate server option or enabling small network buffers in the client have strictly no effect.
Multithreading is also a good way to improve CPU power of your server.

[ignotus666]

I did a little experiment. Connecting to a local server (ping = 0) with -F (fast update for small buffers, also enabled in the client) my overall latencies are:

• At a buffer size of 64: 10 ms
• 48: 10 ms
• 32, 16 and 8: 8 ms

Same jitter buffers for all of them (2, 2). So a buffer size of 32 did shave off a couple of ms, but lower than that did not make a difference.

[npostavs]

Can someone please explain why sometimes Jamulus enforces/enables its 3 Buffer delay choices, while other times it let's the driver decide?

Jamlus calls ASIOGetBufferSize to figure out if the driver supports 64, 128, or 256. If the driver says it supports one or more, then those choices are enabled in the UI. Otherwise, they are disabled, and only the supported size is shown.

https://github.com/jamulussoftware/jamulus/blob/r3_8_1/windows/sound.cpp#L312

By the way, I get better latency with the Interface at 64 than the TD-27 at 48 (which does not make sense to me), circa 5ms improvement in overall delay.

If the audio buffer doesn't fit neatly into the network buffer size (which is usually 128 or in the "small network buffers" case, 64), Jamulus adds an extra step of buffering to compensate.

https://github.com/jamulussoftware/jamulus/blob/r3_8_1/src/client.cpp#L796-L821