Variable auto jitterbuffer.

[jugo6]

Auto jitterbuffer adjustable? It might have been said earlier, but I wouldn't mind a variable jitterbuffer auto setting. For me, dealing mainly with vocals, lack jitter is more important than some extra ms delay. So usually I put the jitterbuffer on auto, take it off again, and put both 1 up, to get even less jitter. After a while sometimes the network has a bad mood, and I have to adjust again. So for changing network conditions I prefer auto, but auto is not clean enough..... At the other hand I also read about people doing the opposite (faders 1 down, like in the help-popup). I don't know if the auto function of the buffer reacts on data already been lost, or if it interacts earlier, but a horizontal slider for auto between quick---|---safe might be practical for these two kinds of people...

[gilgongo]

Yes, this has been mentioned before on the forums and it's an interesting idea I think. I sometimes hang out as a listener on servers to see what people are talking about, and there's often discussion about the complexity of the interaction of buffers and things which can confuse people. But the trade-off between latency and signal integrity seems to be a constant.

One might also imagine a "simple" and "advanced" UI where the current UI is the advanced, and the slider is the simple (is it "quick --|--safe" or some other vocabulary? "more response--|--more integrity"?)

[corrados]

This issue which I see with the request is that the Auto Jitterbuffer functionality is not only located at the client but also at the server. So if I would introduce such a setting, the server would also have to support this since it does not make sense to auto adjust the local/server jitter buffers differently. So we would have to do changes in the client, introduce a new protocol message to tell the server about the setting and do the implementation in the server as well. So there is quite a lot to do. But the bigger concern is that we have a lot of old Jamulus server versions registered at the server lists. So the new feature would not work on most of the registered servers.

[jugo6]

Thanks for thinking along, as gilgongo said it is an frequently discussed subject on different sessions and aftertalks. Of course there are different criteria and circumstances. Recently we finished our Jamulus Choir project with a small streamed festival, and of course just that evening i had an unreliable internet connection. This prompted me to un-auto and add about 10ms finally on both sides..... Once you've figured out tweaking your local buffers, the auto jitterbuffer is the best way still to deal with this, if i could make it more critical :-)

Replying to corrados: combined server-client side makes it more complex yes, i didn't realize that. But we got the pan feature that is also not supported on the older servers. If I am a critical musician i will update both client and server, or choose an updated server, so I think for the users it would not really be a problem. Realizing it in programming is of course another thing. I am not a programmer, but I could imagine a default value which the current auto function now has, and an adjustable value only if the version of server and client allow. Just like the pan-wheel disappears when I connect to an outdated server.

[corrados]

For me, dealing mainly with vocals, lack jitter is more important than some extra ms delay.

Maybe the simplest solution would be to adjust the auto jitter buffer parameters so that you get a bit less drop outs. For the ones who want to have lowest latency possible, they will most probably disable the auto jitter buffer anyway (which I do).

[WolfganP]

Kind of related to this topic, are there any statistic in the pgm showing the amount of packets dropped out, arrived late and discarded, ... that may serve as troubleshooting for bad connections?

[corrados]

Long time ago I have implemented some monitoring tool for showing the error rate of different jitter buffer sizes. If you start Jamulus with --showanalyzerconsole you get a new entry in the view menu. When you click that, you get:

[jugo6]

That is an interesting hidden feature, still not quite clear to me what is shown, are those calculated error rates versus buffer size? I get a slightly different table.

[jugo6]

Auto off for lowest latency: I suppose you have a more stable internet connection, that you can keep it on one value. However it depends on what you're playing perhaps as wel as how much network variability you have. Today I was playing staccato chords in Baggy Trousers, then the jitter bothered me less than in for instance string playing of singing.

[corrados]

I suppose you have a more stable internet connection, that you can keep it on one value.

No, I have a pretty bad internet connection. But if no other device is turned off in my house, the jitter is pretty stable. The issue is that if your son sends a Whatsapp video, you will get many drop outs for a period of, let's say, 10 seconds. In that time the auto jitter buffer turns the buffers up. Then after a while it gets back to the old values. But actually you do not benefit from the increased buffer sizes since during the 10 seconds video upload, you cannot use Jamulus no matter what jitter buffer setting you use. But after the 10 seconds, you can immediately play at a low latency if the auto jitter buffer was disabled.

[corrados]

Maybe the simplest solution would be to adjust the auto jitter buffer parameters so that you get a bit less drop outs.

My question is still open. What are your opinions?

[lefty665]

Suggest making the Auto Jitter Buffer adjustment a little less aggressive, refresh the Jitter Buffer status more frequently, or both. I suspect it will not require a big adjustment to resolve the Auto Buffer under buffer issue. The problem is at the lower margin.

[jugo6]

Maybe the simplest solution would be to adjust the auto jitter buffer parameters so that you get a bit less drop outs.

My question is still open. What are your opinions?

To me that would give a more reliable Auto jitterbuffer. Of course I can't speak for others, as said. When I want to be on the safe side (like performing on worldjam) I add like 2 or 3 ms on both, rehearsing I add less.

Should we do a poll on one of the facebook group how players feel about this/ how much to add?

Making it adjustable would still be my first choice, we had more items like panning that were situated on both client and server side, and were wonderfully updated with backward compatiblilty. Of course thinking on this with more programmers could help, that's the power of open source!

[corrados]

Ok, I have just lowered the droup out probability of the auto jitter buffer algorithm. The change will go into the next release 3.5.10. But it will take some time until the servers will update. So at the beginning only the "local" jitter buffer setting will be changed.

Let's see how the feedback of this change will be.