Publishing ARM Hard Float and ARM64 Packages

Hi. I need some guidance.

Can I publish alternative ARM Hard Float and ARM64 deb packages of VideoBridge2 and Jicofo with:

  • Full build instructions.
  • Direction of support to specific threads.
  • Running a build service to keep the deb packages up to date on a nightly basis where they pass the integrated tests?

I’m not suggesting any changes to the ‘all’ package, these work well for i386 and x64 platforms. These would be new unstable packages suffixed with _armhf and _arm64.

For example:

  • jitsi-meet_x.x.xxxx-x_arm64.deb
  • jitsi-meet-web-config_x.x.xxxx-x_arm64.deb
  • jitsi-meet-web_x.x.xxxx-x_arm64.deb
  • jitsi-meet-tokens_x.x.xxxx-x_arm64.deb
  • jitsi-meet-prosody_x.x.xxxx-x_arm64.deb
  • jitsi-meet-turnserver_x.x.xxxx-x_arm64.deb
1 Like

+1 and include jitsi-videobridge2 :wink:

When you are packaging this, you might like to double check why heartbeats are run in the video bridge with the Sctp routines, when hearbeats are disabled in the configs…

2020-05-25 13:19:44.248 INFO: [15] Performed a successful health check in PT0.044S. Sticky failure: false
2020-05-25 13:19:54.207 INFO: [15] Videobridge.createConference#320: create_conf, id=a5a90f43db681c4c gid=null logging=false

grep -i health /etc/jitsi/videobridge/

@masteryoda do you mind if I ask for your thoughts please? I’m running Jitsi on an 8GB Raspberry Pi, USB 3.0 Key on arm64 Raspberry Pi OS. This is different when the memory limits had to be hacked to make it work on the hard float platform. To be quite frank I’ve put 14 people on a call having regular meetings and it has worked fine. It’s also barely used 2GB of RAM, let alone the 8GB available. Obviously WiFi is a no-go, but why would you? I genuinely believe the network adapter is going to be the limiting factor before the processor or memory.

Yes how good is the perf of the Pi4 network adapter? I’m not talking about the bandwidth - it’s known that Pi4 has effective 1 Gb -, but the interrupt load on the system.

It seems to be not too bad. Enough for me to have 14 people on a call, booting from a USB 3.0 drive with Raspberry Pi OS BETA.

This would never work on a 3B. You can’t and shouldn’t try to do everything with a Raspberry Pi. Even though you can use the 4B as a desktop, there are workloads where even a cheap X64 PC will beat the Pi hands down. But there are a lot of workloads where you would struggle to notice a difference.

What works, works. I’d image most people using a Raspberry Pi 4B would be happy with 4 or 5 people on call. As well as a tinker project, I think Raspberry Pi and the ecosystem allows for a nice Debian based Linux computer. You can either try Jitsi in the cloud or try it on a Pi.

Hi there

My thoughts are that given the effort you put in to set everything up, its better to do it on more powerful machine.

RPi works, but i dont think its suitable if you want to scale it up. I somehow am not comfortable with setting up a video conf/meet server on it. Down the line there might be improvement to jitsi that might need more power. i dont want to be limted & then migrate it over to another machine.

USB3.0 key is not very reliable to run something like the jitsi. the I/O ops will kill it soon

Just my $0.02. I might be wrong & be challenged, but i’d rather spend the time to set it up right

1 Like

To argue for the other side: we all have to start somewhere. There are people who are using Linux for the first time seriously on Raspberry Pis. You can set Jitsi up on your Pi and get some people on a VC. You will learn the limitations. If someone had an old pentium laying around, there is nothing to stop them getting Jitsi Meet and installing it. It wont run well, but you can do it and you’ll learn to use a more powerful machine.

Many of us have learnt our trade. We have access to enterprise level servers either in-house or on the cloud with 8GB of RAM or more paid for by our companies. Many kids are starting out and most people when they are learning do not have access to such machines. They have got a Raspberry Pi 4B at a fixed cost. This version of the machine is far more capable.

To clarify, I’m using an SSD over USB 3. I had used Jitsi on a microSD card (Integral) for 6 weeks and though I don’t recommend it, it didn’t kill the card, crash once or run badly. It was the 4GB version of the 4B, I tried armhf Raspbian; arm64 NSpawn and Ubuntu. I was trying to make a docker image for an 80 core ARM server at the time with 512GB of RAM running Buster. A very nice server, but I only had a production box and not even that at the start due to shipping delays.

The setup and running experience for many applications on ARM is the same as the X64. We have ARM Macs promised. Already have some ARM PCs. The support is the same, if not simpler because you can predict the hardware configurations.

That’s my 2 cents for the other side. I am going to sleep on your comments Master Yoda. I really appreciate your opinion. Thank you.

Guys post your opinion below.

I am also considering dropping armhf from the suggestion. The 8GB Raspberry Pi 4B is the reason I’m taking the ARM version of Jitsi Meet more seriously. Testing it myself, I can’t fault it.

I am not suggesting we run video bridges on Zeros, 1s, 2s or 3s (they really are not powerful enough, sorry.)