I am using a Raspberry Pi 400 Rev 1.0
The webcam for the testing works perfectly on an Intel i7 Windows PC.
This is what I tested…
SD 16 GB - Raspbian GNU/Linux 10
Results using PiKiss Zoom : WebCam Mic not working.
Bluetooth not working with Zoom.
Video in:OK, Video out:OK
Audio in:Unstable, Audio out: Unstable
SD 64GB - Twister OS 1.9
Same as Raspbian GNU/Linux 10, but faster video.
32GB - Android 10 - lineage-17.1-20201121
Results using Android 10 : WebCam Mic not working.
Bluetooth not working on OS.
Video in:Good, Video out: Too unstable.
Audio in:OK, Audio out:NA
USB 128GB - Android 11 - omni-11-20201128-rpi4-MICROG
Results using Android 10 : WebCam Mic and Camera not working.
Bluetooth not working on OS.
Video in:Excelent, Video out: NA.
Audio in:OK, Audio out: NA.
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
I like idea of Chrome Apps, but if it uses NaCl then you should rewrite it, because Google will drop support of Native Client in june 2022. So, every one need to move on WebAssembly
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.
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.
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.
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.
So if you want to go the Chrome app route, flash the FydeOS image to your SD card, and report back how it goes!
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.
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
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.