Manual increases to Jitter Buffer size are not applied in real-time

[walkeral]

Describe the bug
When the Jitter Buffer is on manual (i.e. "Auto" unchecked), lowering the sliders immediately affects the delay (i.e. you can hear the change corresponding with the "Overal Delay"). Raising the sliders back up again does NOT apply any increase to the audio, even though the "Overall Delay" increases.
I do however notice breakup when the sliders are lowered to '1', which then ceases when increased back to '2' or above.

At this point, setting the sliders higher, then disconnecting and reconnecting to the session seems to correctly reset the delay. However I've noticed an additional problem in that if the '-F' option is specified on the server, this disconnect / reconnect does NOT fix clear the problem (and I'm struggling to find what does - the delay seems to drift back up over a few minutes).

To Reproduce

• Open Jamulus settings
• Uncheck "Auto" jitter buffer
• Set both jitter buffers to 20
• Connect session
• Test clicking into mic - observe noticeable audio delay
• Drag both sliders down to 2
• Test clicking into mic - observe considerably less audio delay
• Drag both sliders back to 20
• Test clicking into mic - no change in audio delay
• Disconnect session
• Connect session
• Test clicking into mic - observe noticeable audio delay

Expected behavior
Noticeable audio delay should return immediately when sliders are dragged up to 20, meaning the "Overall Delay" indicator actually matches the audio you are hearing.

Operating system / Versions of Jamulus
Client - Windows 10, version 3.7.0
Server - Ubuntu Linux, reproduced on 3.6.1, 3.6.2 and 3.7.0

I have confirmed the problem by comparing waveforms of what is going to Jamulus and what is coming back from it:

[gene96817]

@walkeral Thank you for creating very clear data for the discussion. I would like to see a diagram of your test configuration.

I will give some observations based on the general theory of buffers since I am not able to read/understand the code.

When you are operating at buffer size 2 and then increase the sliders to 20, I do not expect an immediate increase of delay. The jitter buffer is not intended to be a "delay line" but room to absorb jitter (meaning receiving late packets, which when it catches up does not create a buffer overrun). The delay will increase as transport perturbations occur and packets need to be buffered.

Lowering the buffer size does and should immediately affect the delay since reducing the buffer size means some packets in the buffer has to be discarded.

I believe that if you set the buffer to maximum, initially you will sell low delay. Then, depending on the Internet transport quality (or lack of quality), the delay will slowly increase as more and more jitter has to be absorbed. After each jitter incident, there should be a period of steady-state packet arrival, and the delay will not decrease. Occasionally, the jitter will cause a very long pause in packet delivery, the buffer will drain and the delay will decrease to this new low level of the buffer. Sometimes there is buffer underrun and you will hear a sound glitch. This buffer underrun is "good" in that it resets the delay to a minimum.

I am very interested in this slow accumulation of delay and a discussion about when should the buffer be flushed to reset the delay. Yes, flushing the buffer will cause a sound glitch. I am of the opinion that an occasional flush with a "small" sound glitch is better than hearing the delay grow and grow. Your test configuration could help this discussion by making the phenomena visible.

[walkeral]

Here's a diagram of my setup. I use Cantabile Lite as the DAW software, and ASIO Link Pro to bridge the ASIO between it, Jamulus, and Audition (which is what I took the waveform screenshots in).

[gene96817]

I don't know how to visualize the connection between Cantabile Lite to Jamulus? Perhaps that information is implied by "ASIO Link Pro" master and slave. I don't have any familiarity of ASIO Link. Pro. What are the implied data flows that are not shown?

[gilgongo]

Moving to discussion if we want to pursue this.