I spent some time setting up and trying out Jitsi on Debian. Resource consumption seems acceptable enough for a small group of people to do video chat. While more testing would be better, I believe we can look forward to having Jitsi in FreedomBox.
My setup details:
VirtualBox + Vagrant with Buster image.
2 CPU cores
512 MiB RAM
Added extra network adapter with config.vm.network "private_network", type: "dhcp".
In the host, /etc/hosts added a line like this 172.28.128.3 jitsi.vm.example.
I have followed the Jitsi Handbook to install in Buster. apt install jitsi-web.
Had to make one fix in /usr/share/jitsi-videobridge/jvb.sh to remove option -XX:+UseConcMarkSweepGC since openjdk-15 removed it.
For test call with 2 Firefox windows (different containers) on the host machine. Enabled audio and video on both parties and set them in side-by view.
Resource consumption seems to be pretty acceptable. It might work out okay even for Pioneer box if not it will certainly work well on the likes of RPi 4, RockPro64, etc.
CPU usage is around 10-20%.
Memory usage is around 320MiB for Jitsi Video Bridge + Jitsi Conference Focus + Coturn + Prosody.
I tried with six participants. The host machine was too underpowered to handle six firefox windows all doing simultaneous audio/video. I had to use a desktop machine so the connection was over wireless this time. The video quality for each of participant showed poor icon and I could not bring it up even though I set the quality to high in settings. However, the server resource usage is still promising:
CPU usage was around 40-60% (one core out of two). 30% CPU usage overall.
RAM usage was higher this time about 620MiB for the whole system (swap was used because this is a 512MiB VM).
Network usage is strangely low (possibly because of low quality video) about 2.8Mbps.
Comparing the time it took for the jitsi_ynh integration to apparently stall, to the short time it took for GitHub - YunoHost-Apps/galene_ynh: Galène package for YunoHost to come out, it seems also much much easier to actually integrate into an existing environment.
For one-to-many communication (lectures), the behaviour is linear, and Galène should be able to serve about 400 participants per core. For many-to-many communication (meetings), the behaviour is quadratic (the server load grows as the square of the number of participants), expect to be able to handle on the order of 20 participants in a single meeting on one core, 40 on four cores (more if some participants don’t switch their camera on).
I checked out the project. It looks extremely promising with its scalability and resource consumption. A simple call worked out as expected. Screen sharing and chat worked too. The UI is quite decent. In terms of packaging requirements, it seems to have only a handfull of Go libraries it depends on (which is quite good).
However, on the overall, I could not gain the same level confidence on it as I have on Jitsi. I have been using Jitsi for a while and it seems quite mature. Galene unfortunately seems to have mostly a single contributor, short project history and a low version number. Also due to lack of end-to-encryption and streaming and learning focus it seems more of a competitor to BigBlueButton (which we are also planning to do) than to Jitsi. I really hope we have this app in FreedomBox but I am not sure if it will be able to replace Jitsi for us.
I think we should go ahead with Jitsi and look forward to add this app in future.
Did you get into the jitsi packaging and integration challenge yet? Jitsi seems to have a real long history there, my guess was that new Galène is more likely to enter Debian.
And it’s developing quickly covering both jitsi and BBB use-cases, scaling well to small SBC boards. Aren’t there maybe more debian devs that might be interested?
Looks like pion-sfu is a newer project than Galene. There wasn’t an SFU implementation as part of the pion stack when Galene was started. Though Galene is mostly built on the pion stack, it doesn’t use pion-sfu.
Galene was made to be a replacement for Big Blue Button which is notoriously expensive on server resources (I also have personal experience with this). The user interface also mimics BBB.
I have the same concerns about Galene that Sunil mentioned earlier.
In my opinion, BBB/Galene doesn’t have a good use case for home servers. However, we can consider Galene for University deployments of FreedomBox. Ping @madihaz
Galene is like a proof-of-concept of the very promising pion stack. I look forward to seeing more self-hosted applications built on it.
