Android Auto unuseable slow @1080p

[senfgurke66]

Hello,

i just switched from OAP tu Hudiy.
It worked good after the installation.
After first boot I changed the following settings in $HOME/.hudiy/share/config/main_configuration.json:

appearance, showclock: false
androidAuto, speechAudio = false
androidAuto, mediaAudio = false
andoidAuto, resolution = 1080p
andoidAuto, dpi = 190

Android Auto got unasable slow. Latency between touch and display is >10s. The same is true for keyboard inputs (1,2,arrow keys). Most of the button presses aren't registrated at all.
The spotify play/pause button works suprisingly quick <2sec. Only the visual of the button doesn't change. Seems like the video strem is laggy, but the input works okay-ish.
When changing the AA-resolution to 720p/480p everything works quick and reliable.
The hudiy UI works quick and reliable in all scenarios.

Used HW:
Raspbi 4b
Sony Xperia 10 VI, wifi connection
Waveshare 11.6" Capacative LCD 1920x1080

Does anyone have ideas on how to find the bottleneck?
I don't know where to search.

I'm happy for any feedback!

[hudiy]

Hello, what version of Hudiy do you use?

If you are on 1.0, please update to 1.2 - https://github.com/wiboma/hudiy/blob/ma ... d#updating

[senfgurke66]

Thank you for the quick reply.

I did have the old version and upgraded to 1.2
However it didn't fix the issue.
I noticed two differences:
- 720p is now not in fullscreen.
- 720p is now also unuseable laggy. I didn't try 480.
Same behaviour with the the spotify button working but the videostream not.

Do you have other ideas?

[hudiy]

Hudiy adjusts the size of render surface to the video stream dimensions. To cover the entire screen, resolution should be set to 1080p as there is no upscaling.

Version 1.2 utilizes full zero copy between decoding hardware and GPU so it is not an issue with decoding the video. Could you please post output of wlr-randr command? Also please post content of /boot/firmware/config.txt.

Please also test Android Auto with useRpiDrm set to true https://github.com/wiboma/hudiy/blob/ma ... ndroidauto

[senfgurke66]

Here are the the outputs.

1.JPG (2.54 MiB) Viewed 1049 times

0.JPG (3.01 MiB) Viewed 1049 times

I did change the useRpiDrm setting and that seemed to do the trick.
I get good speed on 1080p 30 and 60fps. 720p is also flawless. I didn't test 480p.
Thank you for the great and quick support!

[senfgurke66]

After some testing on my commuting way (~30min drive) for the last couple weeks I did notice some unusual behaviour:

1. On ~40% of my commutes Hudiy crashes randomly. The displays shows the desktop. After a manual OS restart it works again. On some occasions it even crashes a second time within the 30 min drive, ca. 10% of the time.
Is there a Logfile to trace the error?

2. Is it possible to disable the audio/speech channel on the Pi? I have my phone connected via bluetooth to my car radio, as this is the only input method. When calling people my phone often chooses the Raspi as mic/output. I have to switch manual to the car bluetooth radio in these cases. I remember the disable Speech/Audio option from OAP. I couldn't find it for hudiy, only for the Android Auto subsystem.

3. Hudiy crashes when answering a phone call with a ~80% chance. I usually answer calls with the OEM steering wheel button. This leads to a crash of Hudiy most of the time and I am left with the desktop and a manual reboot.
Is there a Logfile to trace the error?

4. The lagging is coming back after some time. After ~10min I notice the UI is getting slower. This is noticeable with a bad adio stream to the car radio. It gets cracky and has small pauses. The GPS-position on Wave/Google maps has a referesh rate of ~1s. Touch inputs take a long response time (~5s). Car-radio button-inputs as Play/Pause have the same latency.
After a reboot the system is snappy again for the next ~10min.
The poor Audio quality stream is Hudiy/Android Auto depended. With the Raspi turned off the audio stream stays crisp for the whole commute.
Do have any ideas on how to trace the error?

[hudiy]

Hudiy uses the Raspberry Pi's hardware video block to decode Android Auto and CarPlay streams, so there should be no stuttering or lag. The hardware decoder is the most efficient option available on the Raspberry Pi and it can easily handle 1080p at 60 FPS. Since version 1.2, Hudiy has used a zero-copy pipeline - all data sent by the phone (both video and audio) is passed directly into the hardware video decoder and PipeWire without any additional buffering.

In this scenario, the bottleneck is often the phone itself. After long use of Android Auto at high resolution, the phone can heat up and start thermal throttling, which may introduce delays (the phone's SoC slows down to protect itself from overheating). Another factor that increases the device's temperature is simultaneously charging the phone while using wireless Android Auto. The crashes may not come directly from Hudiy, but for example from a corrupted video or audio stream.

Hudiy logs are located in the $HOME/.hudiy/log/hudiy.*.log (where * is a number). You can upload here all the files and we will analyze them.

For now we recommend updating to version 1.4 (if you're using Hudiy on Bookworm) - https://github.com/wiboma/hudiy?tab=rea ... e#updating.

Please also provide detailed information about the components used in your setup - the exact Raspberry Pi model (RAM), power supply, audio hardware and any other peripherals connected to the Raspberry Pi.

[senfgurke66]

Hi,
sorry for the late reply, I had no access to my car the last week.
I did attatch a commented photo of my Hardware setup. The electronics are mounted on the backside of the display.
There's some additional electronics for switchtig the power supply of the Raspi and the Display on and off.
I did also attatch two logfiles. I don't have more files in the folder.

I don't think the phone hardware is the limiting factor here. It's not getting warm in my pocket.
After a Hudiy reboot it's fluent again. This indicates some kind of buffer overflow for me. An overheat error would still be present after a reboot.
I do use my phone with Android Auto on some of the company car's from time to time. I do not have problems there.

I will do the update to version 1.4. All the logs are still with version 1.2.

Thanks for your help!

[hudiy]

We checked the logs and in several places we can see that the phone did not respond to the ping (response time > 5s). It can be caused, for example, by moving too far away from the Raspberry Pi with your phone or when the WiFi connection becomes weak for some other reason.

[2025-11-10 00:14:38.114139] [0x0000007f5efddbc0] [error] [hudiy] [AndroidAutoEntity] device not responding, pings: 362, pongs: 360
[2025-11-10 01:37:37.936419] [0x0000007f73ffdbc0] [error] [hudiy] [AndroidAutoEntity] device not responding, pings: 139, pongs: 137
[2025-11-10 01:50:49.295849] [0x0000007f72fddbc0] [error] [hudiy] [AndroidAutoEntity] device not responding, pings: 3, pongs: 1
[2025-11-10 02:04:41.613703] [0x0000007f67ffdbc0] [error] [hudiy] [AndroidAutoEntity] device not responding, pings: 4, pongs: 2
[2025-11-10 02:23:13.090659] [0x0000007f72fddbc0] [error] [hudiy] [AndroidAutoEntity] device not responding, pings: 9, pongs: 7
[2025-11-10 02:45:50.036093] [0x0000007f74f9dbc0] [error] [hudiy] [AndroidAutoEntity] device not responding, pings: 75, pongs: 73
[2025-11-10 04:21:13.061851] [0x0000007f61fbdbc0] [error] [hudiy] [AndroidAutoEntity] device not responding, pings: 312, pongs: 310
[2025-11-10 04:44:28.957558] [0x0000007f57ffdbc0] [error] [hudiy] [AndroidAutoEntity] device not responding, pings: 95, pongs: 93
[2025-11-10 06:06:57.207081] [0x0000007f69fbdbc0] [error] [hudiy] [AndroidAutoEntity] device not responding, pings: 383, pongs: 381
[2025-11-10 07:31:03.347874] [0x0000007f67ffdbc0] [error] [hudiy] [AndroidAutoEntity] device not responding, pings: 412, pongs: 410

We can also see occasional Bluetooth reconnect floods in the logs.

As a configuration improvement, you can use the Bluetooth MAC address of your head unit so that it is sent to Android Auto instead of the Raspberry Pi's Bluetooth MAC address:

https://github.com/wiboma/hudiy/blob/ma ... ndroidauto (bluetoothAddress).

The Raspberry Pi uses a shared chip for both Bluetooth and WiFi, so this kind of Bluetooth reconnect flood may be causing some stalls in the Raspberry Pi's Bluetooth/WiFi firmware or driver but this may be difficult to detect in the logs (It's probably something that can only be detected in pcaps). The simplest check would be to disable the built-in Bluetooth and use a cheap USB dongle instead, to offload the Raspberry Pi's wireless chip and check whether the issue still occurs.

[senfgurke66]

Thanks for checking the Logs.
The reconnects could also be caused by me being close to the car after leaving it.
Th Rapsberry will run another 20min after Turning the car off.

However, I made a new install based on Trixie and added an external bluetooth adapter.
The first hour of Desk testing looks promising.

Are there news on how to disable the speech channel for Hudiy?
My phone still wants to use the Rapsi for phone calls.
When turning the calls option in my phone menu off, the Raspi won't connect to my phone "No useable services on this device"