Explanation please - on jitter and buffer sizes

[openaspace]

Hello.
I can ask you why in some peers the remote channells client are flashing randomly?

Thankyou

[christofmuc]

This usually indicates the buffers are too small. When the jitter is larger than the buffer sizes allow, a connection is dropped (well, it is UDP traffic so there is no connection, but this means that no package has been received in time). After a short time, the participant is assumed to be gone and the remote channel is removed. This happens too quickly right now - but it indicates that you need larger buffer sizes. The client side buffers can be set with the sliders in the UI, but the server side buffers are command line parameters to the server executable.

I recommend running the server from the command line and watching the output - it displays the jitter of each participant's data coming in.

[openaspace]

thank you.

I see: Feb 26 15:00:13 ip-aws JammerNetzServer[597]: Client my-wan-ip:8935: New client connected, first package received Feb 26 15:00:15 ip-aws JammerNetzServer[597]: Client my-wan-ip:8935: Jitter queue underrun, removing from client list in mix!

I have tried to change client buffer but nothing change. Sorry how I can set more large buffer in the server command line? I mean a large server bufffer will only encrease the buffer but not will encrease obbligatory the latency?

[openaspace]

the participants are with ping from 5 to 10 to 20ms.. also i see that the problem sometimes is less present on different type of audio sound cards.

For the same server, to explain what we works for us with jamulus... we have minimu client buffer of 2.67ms and server jitter
buffer 7. ping 9ms with total delay 26ms

[christofmuc]

The buffers are not fixed (only the minimum buffer), so adding large numbers doesn't lead to a higher latency when there is no jitter.

The server has three different settings:

• Specify the length of the incoming jitter buffer in blocks with -b
• Specify the maximum length of the incoming buffer in blocks before continuing mixing with -w
• Specify the number of packets a client needs to send before becoming part of the mix (minimum queue length) with -p

The default setting is at

• -b Packages needed minimum in queue: 3 (or 8 ms)
• -w Packages accumulated before deciding the others are not going to send (maximum wait time for the others to provide audio): 5 (or 13,33 ms)
• -p Packages prefilled when a client comes back online: 3

The prefill is meant for dealing with drops instead of jitter, you could try to set it to 0 if you know you have higher jitter but no drops. Also, start adding a higher wait time (at the price of higher latency) to see if you can get a stable connection first and then try to move values down from there to get faster.

It is also possible to compile with buffer size 64 instead of 128, but I haven't tested that for a while. Should also make a difference!
That's to be changed in the file BuffersConfig.h.

[christofmuc]

so you could try

JammerNetzServer -b 5 -w 10 -p 5

and incresase the sliders in the clients for a start. If that works without disconnects, you can start decreasing values. Also, sometimes the flicker can be seen but not heard. Did you check th audio quality, do you hear clicks and crackles when it flickers?

[christofmuc]

Ping btw is less important than jitter, which is why I added jitter measurement into the server, you ca see it displayed in the last 2 columns, Jitter ms (milliseconds) and Jitter SD (Standard deviation).

[openaspace]

Thank you. I will try soon. (there is no way to run the client on high sierra?..tried to compile with brew without success)

[christofmuc]

High Sierra should work as far as I recall.

Did you try the precompiled binaries I have here? https://github.com/christofmuc/JammerNetz/releases

[openaspace]

Did you try the precompiled binaries I have here? https://github.com/christofmuc/JammerNetz/releases

require 10.14 and i have 10.13.6 (on a mac pro 2009 with a flashed firmware to 2010 and I can't upgrade to 10.14)

[christofmuc]

Hm, not sure where the requirement comes from. Maybe C++ 17 support (which is required).

The CMakeFile.txt says

# Target a specific macOS version to allow older hardware to run the client
set(CMAKE_OSX_DEPLOYMENT_TARGET "10.11" CACHE STRING "Minimum OS X version to target for deployment")

but something other seems to ignore that.

[openaspace]

You are really kind thank you. Unfortunately with opencore and Sonoma there are serious problems with audio over USB