We are using the Meeting SDK for Linux, version 5.17.11.3885, to allow a Bot to join meetings attended by our users, capture Mixed Audio Rawdata, and send it to our service. The Bot operates in a container in our cloud service infrastructure, so it does not utilize resources on the user’s PC.
However, we have received the following report from a user:
“After the Bot joins the meeting, is granted permission to record, and recording begins, the CPU usage of the Zoom application on the participant’s PC increases significantly, making it difficult to continue the meeting.”
To clarify, we have two main questions:
When Rawdata is captured by the Meeting SDK, is it streamed from Zoom’s servers directly to the Meeting SDK, or could it be streamed directly from the user’s Zoom application instead?
Our Bot captures audio only, and therefore we have not initialized any Rawdata Renderer for video. Is it necessary to explicitly specify that video is not in use to avoid unintended impacts on participants’ Zoom applications?
For meetings in general, audio and video typically goes thru the cloud before going to the recipient, in your case it should go to the cloud before going to your Linux SDK running on docker.
There is another scenario where the data is sent directly to the Linux SDK if peer to peer connection is enabled.
Both of the scenario above should not cause the sender’s CPU to spike up dramatically to the extend where if is difficult to continue the meeting, unless the PC is severely underpowered.
Hey @mutsuo.masui, as Chun Siong mentioned, the bot is unlikely to have any meaningful impact on the end user’s own CPU/hardware due to how the data is transferred.
With that said, we run meeting bots at a large scale ourselves and have had customers report similar concerns. One thing that we’ve found helpful in these scenarios is to have the user update their Zoom client and OS, which can help mitigate any possible CPU performance issues they’re experiencing.
It’s a simple 3rd party API that lets you use meeting bots to get raw audio/video/metadata from meetings without you needing to spend months to build, scale and maintain these bots.
It seems likely that the problem is with the PC of the user participating in the meeting using the Zoom application.
By the way, if there are two people participating in the meeting and one bot participating using the Meeting SDK, will it still not be a peer-to-peer connection? In other words, are participants using the Meeting SDK also counted as part of the number of people used to determine whether a P2P connection is made, just like participants using the Zoom application?
I understand that the bot itself is unlikely to have a significant impact on the end user’s CPU or hardware, given how data is transferred. However, I appreciate your point about users potentially experiencing performance issues and will suggest they update their Zoom client and operating system to mitigate this.
Regarding the Recall.ai API, I appreciate the recommendation. While it seems like a convenient option for accessing raw audio/video/metadata from meetings, our current implementation is deeply integrated with the Zoom Meeting SDK to fit our specific needs, and we have already established infrastructure for bot deployment. Nevertheless, I’ll keep Recall.ai in mind for future considerations, especially if we decide to explore alternative solutions.