It appears they’ve fixed the screen tearing issues that I mentioned last time.
I think that Arm (armhf and arm64) Linux version would be great, but I think that much easier will be improve web version. So I added my request about missing functionality in web version here
Please develop ARM version, it is a very cheap solution to use RPI.
Please develop a native arm client.
I use my pi almost as my main computer, but one of the only things stopping me is that I need zoom.
I think enough people are interested in a arm version for you to start making it.
I also would like Zoom to develop an ARM client.
ARM seems to be the way forward (even Apple is using it) and the impact would be huge now that the world needs to study remotely and most of the world don’t have access to costly computers.
hello, link about solution?
It is not really a question of developing. Given zoom already works on many Linux distros, unless it is written in x86 assembly, it will probably be a small exercise to recompile it on PiOS.
I am sure the Raspberry Foundation will be more than happy to help.
The Chrome App on a Pi just displays an endless “Connecting…”, the quality of video & audio on the WebVersion is poor and something like this GitHub - Botspot/pi-apps: Raspberry Pi App Store for Open Source Projects improves but not enough to make it usable.
Think of all the children home schooling, you could really get good PR return on a small investment.
Actually, there is a workaround to the “Connecting…” issue.
This is due to Raspbian’s Chromium not supporting NaCl browser technology (Native Client).
As per my request, RPi’s ChromebookOS DOES now support NaCl. Last time I tried it, there were various graphics glitches, but they say they’ve improved.
I have tried the Box86 solution, and it is the best, so far. Though, it still has a number of issues, especially in cases of slower (sub-gig) networks. I also support many Pi3 users, and the Box86 solution chokes hard. As most home users and WFH employees are also restricted by available bandwidth, the only suitable solution is to have a genuine ARM client.
what about qemu-static or compiling anbox and running the android version. There is also GitHub - FydeOS/chromium_os-raspberry_pi: Build your Chromium OS for Raspberry Pi 3B/3B+/4B and Pi400 and using the chromeOS version.
I also totally support Zoom native app on Raspberry Pi.
I agree with all, zoom must definitely support arm64. Raspi is the cheapest solution for remote work or students
I agree with all, zoom must definitely support arm64
I also agree. I believe that it is especially important now more than ever because of campaigns like what the Raspberry Pi Foundation is doing with the Pi 400. They have already gotten around 5,000 Pi 400s in the hands of children that could not afford to purchase a modern amd64 desktop computer.
The Raspberry Pi Foundation, from what I can understand, is intending to expand the program to give more low-income students access to reasonably powerful (in my opinion), but cheap computer hardware. Unfortunately, these students are currently forced to use the Zoom webapp for classes. The webapp, if I might add, performs very poorly on the Raspberry Pi 400 in it’s current state, especially when the webcam is turned on. I find this to not be the fault of the Pi 400 hardware, but rather the Zoom webapp and the lack of native builds of the desktop client.
I would love to see native aarch64 (arm64) and armhf (arm) builds of the Zoom desktop client for Linux. because more and more people are going to be using Linux on ARM. if the Raspberry Pi Foundation keeps this up (which definitely appears to be the case) In my opinion, it is in the best interest of both the end-users of the Zoom software, and Zoom Video Communications to produce builds for Linux on the 32-bit and 64-bit arm platforms. The Zoom software could gain a previously untapped user-base and the end-users would have a significantly better experience with the Zoom software.
Yes, this is absolutely needed. RPI’s aren’t the most powerful of computers so while emulation works, it’s far from being the best solution… Native support is crucial there
How hard can it be when it already works 32/64 bit for so many linux distros?
Have you written it in x86 assembly?
Not sure if this has been mentioned or not; running the web app on raspberry pi 4 with anything less than a fiber connection is holey unsatisfactory. The combination of Chromium and the web interface create too many layers and the handshaking kills the app.
I want to add another two cents, to say, if this were an open source project, the community would have solved this issue a long time ago. Remember, the price of closed source is the requirement of providing service to the user base. If it is viewed by the decision makers, that Raspberry Pi is not a large enough market to invest resources, then provide a true SDK, so someone can.
A year has passed. Could you please update if Zoom on raspberry pi is in the roadmap? Is there any timeline the company has in mind?
I’ve tried the FydeOS/ChromiumOS solution. I’ve read into the NaCl issues too which may be resolved once v90 is built into it. But even if it is, support has been pulled for it going forward, so it’s not a long term solution.
The source of the poor performance is that zoom is using CPU encoding/decoding which a Pi isn’t fast enough for. As the built in encoders are relatively low compression I can’t see zoom wanting to use them.
Zoom prioritizes bandwidth which is a cost to them over hardware performance which is a cost to the user. It’s the same reason M$ use the silk codec in skype and teams.
It sucks because the educational users could really use it. Maybe a hypothetical Pi5 will be powerful enough but we aren’t there yet,
I don’t want the post to be removed, so all I’ll say is that there are alternatives which do work smoothly and are free.