Poor mouse and webcam performance


I’m following the great guide here to set-up my grandparents’ videoconferencing.
All went fine, but I seem to have two performance issues. Here’s the symptoms:

  1. Mouse cursor is lagging. After setting SHOW_CURSOR to 1, I need to be extremely slow that the cursor is rendered correctly.
  2. Video camera in Jitsi meet (Kiosk mode in Chrome) starts for about 10 seconds, starts lagging and then crashes completely. However, incoming video of other participants is smooth.
  3. If I start the microphone as well, the camera just flashes for 1 sec and crashes immediately.

This led me to some performance investigation. CPU and memory looks good (also verified via top command via ssh), so I tried to set RESIN_HOST_CONFIG_gpu_mem to 256, or even 512. No luck there :frowning:

Some more info:
OS: balenaOS 2.56.0+rev1
Webcam: Logitech HD Webcam C525
rPI: version 4B [4GM RAM]

Can you give me some tips on how can I debug and potentially fix this?

Many thanks!

Hi Petr, sorry this does not work for you.
A lagging mouse cursor points to some process hogging cpu cycles… Does this occur only when the camera is plugged in and jitsi is running ?
I can take a look at the device for you if you grant support access and send me the device URL.
Otherwise I can contact the maintainer of the project and see if he can help…
Regards Thomas

Hi Thomas,
Thanks for reaching out that quickly.
Access granted, I’ll send you the link privately.

Regarding your question - CPU looks good actually, both in the Balena dashboard and if I look via ssh. I should also add – even if I remove the camera or try other than the Jitsi page, the mouse is still super laggy.

Any other pointers are welcome :slight_smile:

One difference I see in your setup compared to the instructions, is that you have your variables in the dashboard set up as device variables instead of as device service variables. This leads to all services being restarted when you change a variable although they are only meant for the kiosk service. I don’t think that would lead to the problems you experience but it might be worth a shot.
Otherwise I can see that your device seems unresponsive at times even via ssh but I can not seem to figure out what is causing this…

Thanks for giving this a shot Thomas.
I tried moving the variables to a different scope [had it even fleet-wide], but as you expected, it is still the same.
I’ve also tried flashing older balenaOS from the time of the manual, still same. I’m going to try different monitor/mouse tomorrow, but running out of other ideas I’m afraid…

Hey there @flaesh

This project should work quite well on a Pi4 with 4GB of RAM.

  • Can you confirm which type of sd card you are using? Slow sd card speeds might explain some of this behavior. We recommend SanDisk Extreme Pro SD cards.
  • Is the pi overheating? this might cause the CPU to throttle too
  • Can you try the following settings to see if it helps?
    • change the gpu_mem to 256mb
    • add a service variable for the kiosk service FLAGS="--disable-dev-shm-usage --autoplay-policy=no-user-gesture-required --noerrdialogs --disable-session-crashed-bubble --check-for-update-interval=31536000"

hopefully, these suggestions help


Hi Rahul,

Thanks for the great suggestions.

I can confirm that I have the SanDisk Extreme Pro card and the PI is not overheating [I even have a passive cooler on top of it].
I’ve changed the gpu_mem to 256mb and set the variable for the kiosk service, as you’ve suggested. The video was running for a little longer smoothly [about 30 sec], but then it started to slow down, mouse started to lag and the camera then switched off itself. After the camera switched off, mouse started to behave normally again.

Maybe this has something to do with energy requirements of the webcam? It’s connected in the USB3 port.


Hi Petr, That’s interesting, thanks.
To follow up on the webcam power requirements theory, you could check for undervoltage events.
To do this, go to the balena dashboard for that device, and click the Diagnostics button on the botton left, then click the run checks button. After the checks have completed, you should see an entry for check_under_voltage.
Could you tell us what you see there please?

Tried the undervoltage events diagnostics, but it looks good. Report says “No under-voltage events detected”. So, I guess that theory might not be valid.

Another theory I’m thinking of is simply PIs performance, since the camera is FullHD. There is this thread here that suggests flashing older eeprom.

I tried the following as root:

wget https://github.com/raspberrypi/rpi-eeprom/raw/master/firmware/critical/vl805-000137ad.bin
rpi-eeprom-update -u ./vl805-000137ad.bin

…but it seems rpi-eeprom is not part of balenaOS, since I get:

bash: rpi-eeprom-update: command not found

What do you think about exploring this route?

Update here: I was able to borrow a friend’s other webcam and the issue is gone. So, the final suspect is my (brand new) Logitech HD Webcam C525 webcam, which somehow gives rPi a bad time for unknown reasons.
If there’s ideas how we can debug webcam issues on balenaOS, that’d be great! Thank you!

Ok, final update after much investigations:
It seems there’s an issue with the USB ports, as described here. The solution seems to be updating PIs firmware, as described here.

Unfortunately, balenaOS seems to not have the capabilities to do so, since the bootloader sw is intentionally missing, as described in the open Issue here and in the commit here.

Phew. At this point, seems I’ll need to update the bootloader firmware, then. Either to older version, or this newer one. Could the nice guys from balenaOS help out?

Many thanks!

One really quick thought to help get you on your way faster, is to flash a second SD Card with Raspbian, boot up, and run/install all updates. It should download and install the latest version of the rpi-eeprom , thus upgrading the onboard firmware on the Pi. Once complete, power down, and re-insert the balena SD Card, and see if the issue is resolved. Perhaps that will do the trick?

Wow, that did the trick! Upgrading the eeprom via the standard RaspberryOS indeed persisted.
Super cool, thanks for the support from all the Balena team here, gotta deploy more devices now :slight_smile:

1 Like

Glad to hear it resolved it :grin:

1 Like