64 or 128 samples which is the really preferred setting?

[henkdegroot]

According to the website software manual, 64 samples is the preferred setting to use for the Buffer.
However the text in the GUI dialog indicates 128 samples is the preferred option.

Which is the correct one?

One of them should change....

[jujudusud]

128 is the preferred. The error is in the software manuel.

[jujudusud]

I think it is ok in the next release branch.
Could you check ?

[jujudusud]

I'm afraid it is not the case.
Yet I was shure that @gilgongo had made this change...
I will propose a PR tonight if it is not the case.

[gilgongo]

Must have forgotten. I've updated the EN docs on next-release branch.

[jujudusud]

I will do that tonight.

[jujudusud]

Finaly done the translation only for next-release. No PR from me in this context.

[dcorson-ticino-com]

I think the question is, by which criteria do we decide which is the preferred buffer size ?
If your compi and Internet connection allow it, 64 will give you less latency, with small buffers checked even better.

[gilgongo]

We could maybe say that it's worth experimenting sometimes though. There are people who report (myself among them) that they get better overall delay using 128 than 64, even when their hardware supports 64. Quite why, I don't know though.

[jp8]

I believe that is due to jitter. The 'small network buffers' setting is more prone to jitter, and performs worse on even a slightly jittery connection.

[hoffie]

In my experience:

• If small network buffers work (i.e. depending on alignment with audio capturing frame sizes), it will reduce latency. This can be hugely helpful, especially when latency is high due to other factors. Example: I've had very bad connectivity recently (apparently mainly late packets) which was compensated somehow by very large jitter buffer sizes (close to maximum). Running with small network buffers helped a lot.
• Small network buffer audio quality is worse in theory (probably due to opus working worse on smaller samples). However, if other factors (e.g. network problems) destroy the Jamulus experience for you without Small network buffers, it may still be useful to enable this feature.
• If you are suffering from packet loss (e.g. interference in the cable network as in my case), the overall experience may be better by using Small network buffers as the chance of at least some packets making it through without errors is higher.

In summary: It depends...

Technically, we might want to hide/disable this option if it doesn't make sense due to sound capturing limitations.
Documentation-wise, it might make sense to advise playing around with it, e.g. "Try enabling this option if you are suffering from high latency or bad audio quality. Keeping it disabled will usually yield better audio quality though."

[gene96817]

if the buffers are truly buffers, there should be an insignificant difference in latency. The difference in size is should really be about the ability to handle more jitter. If this is all true, then we don't need to give users a choice in buffer size. If there is a significant addition of latency with the larger size option, I suggest looking at how the buffers are implemented. (Sometimes buffers are used as delay lines to add latency. I don't expect this with Jamulus.)

[gilgongo]

I've added some clarification to the docs on this. jamulussoftware/jamuluswebsite@2218bdf#diff-53d178b0a7e5f38d0fb16c2775b5c80fa0f3c47d74c14dddcaa93450b107e087