Performance improvement suggestions

[jokubasv]

Greetings, this is a very interesting project and I decided to buy it for testing. I love the UI, it's very clean and lean. However, Android Auto performance is very disappointing.

With resolutions higher than 480p, there is huge latency between touch input and changes on screen - this is indicated by a single core being maxed out to close to 100%.

Since this is a closed source project, it's hard to debug the issue, but please consider adding in some tweaks to the gstreamer pipeline, as on my openDash fork gstreamer and AA performance is vastly superior: https://github.com/jokubasver/openauto/ ... ut.cpp#L53

It would also be great to add support for EGLFS instead of relying on Wayland/xcb - this way even Lite versions of Raspberry Pi OS could be used without a desktop environment, increasing boot times, minimizing system resources and increasing performance even further.

Also, it would be beneficial to use hostapd instead of NetworkManager to setup a WiFi hotspot, as NetworkManager can't set the channel width and therefore the max bandwidth is very limited. With hostapd, a 5GHz 80MHz hotspot can be setup, eliminating WiFi bottlenecks and ensuring maximum speed.

Looking forward to seeing where hudiy goes next! Good luck.

[hudiy]

Hello,
Thank you very much for your suggestion and for the kind words about the project.

Hudiy uses an asynchronous engine to distribute the load across all Raspberry Pi cores. We’re currently testing the stability of changes we plan to release in the next update. Thanks to zero-copy and DMA, we’ve managed to significantly improve the performance of Android Auto and CarPlay.

NetworkManager provides greater flexibility and makes it easier to port Hudiy to other or newer system versions. It has now become the standard in many Linux distributions.

However, if in your case hostapd works better, you can disable hotspot creation in Hudiy, set up your own hotspot using hostapd, and configure Android Auto to use it via https://github.com/wiboma/hudiy/blob/ma ... md#hotspot

We’ll also look into the possibility of running Hudiy without a desktop environment.

You can also check the performance of Android Auto in our video: www.youtube.com/watch?v=iqYcBCl7PJk&t=135. In this video, Android Auto is configured to 720p.

During our tests, we also didn’t observe CPU usage higher than 3–4%. The load is evenly distributed across all CPU cores.

We’ll be happy to help identify the cause of the mentioned input lag and high CPU usage in your setup.
Could you please provide more details about the hardware you’re using (Raspberry Pi model, display, and other peripherals)?

[jokubasv]

I'm using a Raspberry Pi 4B 2GB. Display is a Waveshare 5.5inch 1440x2560 HDMI monitor. OS is stock, unchanged Raspberry Pi OS 64-bit, no other peripherals connected.

EDIT: I'm now thinking if the display rotation is what kills the performance - as this waveshare display is a vertical one, rotation is done by the Pi and I'm seeing posts online that this massively impacts performance (frame is sent to a buffer, pixels rotated, and then pushed back to the HDMI port)

[hudiy]

According to information from Raspberry Pi Foundation engineers, the transposer (part of the Hardware Video Scaler [HVS] block) supports resolutions up to 1920x1080. This is why we have limited the supported resolution per screen in Hudiy to 1920x1080.

As far as we know, the hardware block in the Raspberry Pi 4B responsible for video decoding has a similar limitation (1920x1080).

If your display has a built-in scaling chip, you can set the Raspberry Pi output resolution to 1080p, and the display should automatically upscale it to 2560x1440.

[hudiy]

Good news. We successfully set up a hotspot with NetworkManager on Trixie + Raspberry Pi 5 using an 80 MHz channel width. It still needs testing on the Pi 4B, but the results look promising.

Interface wlan0
ifindex 3
wdev 0x1
addr xx:xx:xx:xx:xx:xx
ssid Hudiy
type AP
wiphy 0
channel 36 (5180 MHz), width: 80 MHz, center1: 5210 MHz
txpower 31.00 dBm

Edit:
Works also on Pi 4B.

[hudiy]

It would also be great to add support for EGLFS instead of relying on Wayland/xcb - this way even Lite versions of Raspberry Pi OS could be used without a desktop environment, increasing boot times, minimizing system resources and increasing performance even further.

We tested running Hudiy with the eglfs platform plugin included with Raspberry Pi OS, and everything seems to work correctly. Hardware-accelerated decoding is also available. So it appears that running Hudiy without a desktop environment is mostly just a matter of Raspberry Pi OS configuration.

The downside is that screen setup is a bit more complicated (since the Screen Configuration Tool isn't available on the Lite version). There's also no support for multiple displays. We also didn't notice any significant difference in boot time between console mode and desktop mode, nor in performance - on either the Pi 4b or Pi 5.

A better and way easier approach is simply to disable pcmanfm and wf-panel-pi in the Labwc autostart if you don't need them. kanshi and labwc are very lightweight programs and don't affect boot time. They also provide convenient display management (e.g., screen rotations).

Since running Hudiy with eglfs doesn't require any modifications on Hudiy's side, you can still test it without a desktop environment and see if it's more beneficial for your use case.