I’m not a programer/dev, just a music teacher who enjoys tinkering with tech. I’ve been using someone’s paid Jitsi service, but I will need it less plus I like the idea of running it myself. I’ve got Jitsi running in an Ubuntu VM in my home, using the DDNS built into my Asus router. I know I’ll have to export the SSL keys when the router renews them, but other than that, I think this will work well.
I am wondering if there’s anything more I can turn off more optimize the connection? My clients probably don’t have much tech knowledge, and are probably using older or provided routers. Internet around there is quasi-rural, we do have access to 2 major companies, but the best upload speed is 10Mbps. Most of them are using older PCs or school provided Chromebooks. My current service caps resolution and fps, which I imagine helps the connection remain stable. As much as I’d like to hit 720p, the one test I’ve done so far wasn’t as stable (some freezes, resolution changes), though the latency was crazy low (33ms). I don’t need a whiteboard or the option to record, just a stable 1-on-1 connection with good audio.
So far I’ve set disableAudioLevels: true and enableNoisyMicDetection: false hopefully those will help the client side CPU loads. And also disableACG:true and disableHPF:true for better audio in dealing with wind instruments. Is there anything more I can adjust to ensure a stable connection? I’m going to try to limit video to 540p and 15fps next.
Thanks in advance. Like I said, I’m not a developer, so please bear with me.
I don’t think you need to waste your time fine tuning more. If it works good enough, there will not be any silver bullet that will insulate you of bad network. I used to think that there was something called Opus redundancy that could boost sound reliability (at a video resolution price of course) but after checking it more I realized that it was doing the squared root of nothing (at least when I tested 2 months ago IIRC), my best guess is that it has been added to Jitsi-meet to boost sound quality when using Octo, since it does not seem to be supported by browsers really and it should be useful only when transfering sound between Jitsi-meet servers.
One possibilty could be for you to use VP9 because it will shave some bandwidth for video, and as a music teacher I think that high video resolution is more a ‘nice to have’ that a ‘really imperative’, so having a few more network time for sound packets available could help, especially with low performance network. The only caveat could be that some terminals have problem with VP9, if it does not work at all downgrading to VP8 should happen, but if it does not work well it could be a show stopper. Good luck.
My first 2 test calls on the standard config were so/so. One said it sounded better than usual (an older but audio tuned version of Jitsi), while both saw bandwidth fluctuations causing the video quality to suffer. I set the fps to 15, which I think will help stabilize that. I’ll work my way down to 540 or 480 if there are still issues.
I set the opusMaxAverageBitrate: 48000 and enableOpusRed: true.
I am curious what effect disableSimulcast: true and enableLayerSuspension:false may have on the bandwidth and call quality.
As onboard as I would be with VP9, many of my clients are using school provided Chromebooks, so I imagine their hardware is limited. I do have them all trained to connect with a Chrome browser, which I imagine helps stability.
I saw the new update enabled computer audio sharing, but somehow I don’t get the checkbox for anything other than another tab when using Chrome or Edge. That would be nice, but I can live without it.
This is affective in conferences that are not p2p, when someone is not looking at your HD stream, your client is instructed to turn off and not send the HD stream and/or SD stream depends what people are looking at.
thanks for the correction, it’s clear that with VP8 it’s not just possible since the multi-resolution scheme is managed outside of the browser, however should not layer suspension be at least theoretically possible with Vp9 even in the p2p case ?
It’s thinkable that the browser takes by itself the decision to suspend higher resolution if bandwidth is too low. It would be logical given the design goal of Vp9. If this is the case the parameter is useless anyway.
It’s the other way around, using signaling we inform the browser that nobody is watching its HD stream so it doesn’t need to send it. So even if bandwidth is enough we don’t waste it by sending data that will just reach the jvb and nobody will see.
And it is the client who makes changes to its local description to instruct the browser to skip the higher resolution stream.
It sounds like nether disableSimulcast nor enableLayerSuspension have much affect on my p2p meetings. I think the biggest factor in helping stabilize the bandwidth is limiting the fps to 15. It’s been good, even to 720 the few tests I’ve done. I still may lower to 540, just to help some of those on lesser equipment.
Oddly enough, students have noticed I sound quieter on the newer version of Jitsi. It may just be my settings are a little different. Even though I had Echo cancellation on, I still heard quite a bit of echo, so I turned on noise suppression as well.