hudiy.eu

I've been getting this lately all the time and that mixed with the phone calls dropping every 30s have made me stop using Hudify if I'm honest. I don't have the time to constantly troubleshoot and provide logs - the product is meant to be out of the box. Hopefully with the next update some improvements will be made and then time allowing I can troubleshoot.

With this audio stuttering and crackling I noticed it is only happening during android auto projection. If I exit android auto and go back to the Hudify screen it plays perfectly. Feels like a bandwidth issue.
Raspi4
Carpihat dac
Creative soundcard for mic in
11.7 waveshare screen
Onboard Bluetooth
Wireless AA

Implemented the Bluetooth fix to stop the calls disconnecting that is mentioned in another thread but this crackling and popping still exists within Android Auto.

Has anyone else made progress on this?
Are we maybe running AA at too high a resolution and the projection is taking up too much bandwidth at the expense of the audio quality? I'm just curious it might be that because exiting AA and only running Hudiy makes it go away.

But I do agree. Absolute vibe killer.

Does it happen also with USB connection?

In the case of a slow or insufficient Wi-Fi connection, you’d usually see playback delays rather than stuttering. Hudiy simply forwards whatever it receives from Android Auto directly to PipeWire, so if the issue were on Hudiy’s or PipeWire’s side, you’d expect growing latency instead of audio frames being dropped — Hudiy and PipeWire don’t drop audio frames.

If you’re hearing stuttering or cutting, it’s most likely that the phone isn’t managing to send audio frames on time. That would also explain why playback is fine when projection is inactive: the phone’s CPU load drops, leaving more resources for audio handling.

Does this happen only with a specific player (e.g., Spotify), or across all Android Auto apps (e.g., YouTube Music)? And is it only music playback, or do you also notice problems with other sounds, such as the voice assistant?

A potential solution could be to increase buffering in PipeWire (so playback would only start after a specific number of audio frames have been received).
We’ll take a look at the PipeWire documentation to see if such a setting is possible.

Haven't been able to test this with a USB cable today but have tried it since updating to V1.2 and it is greatly improved but not completely solved.
In normal use (Android Auto navigating with google maps and playing spotify, displaying both on a widescreen) there are no pops or skips but the odd subtle crackle. This however does not stop/skip/judder like it did previously. So greatly improved.

However in the same test while spotify was playing and google maps was on screen but not navigating I opened by phone to select a location to navigate to. The phone itself lagged SEVERELY and the music skipped and popped worse than I've ever heard it. Complete meltdown. Phone was unusable. It was wirelessly charging at the time - and I instantly removed the charger but this did not solve the issue. The only solution to resume use was to exit Android Auto in Hudiy and go back to the main Hudiy screen. Once the Android Auto projection ceased the problem went away. I selected my point to navigate to and relaunched AA. No issues after.

Very strange and possibly worrying. The phone is a Pixel 8 Pro so plenty of power.

Thanks for testing and for the feedback.
A takeaway from how your phone behaves is that it might be thermal throttling on the Pixel.
In our test setups we use a Pixel 6 Pro; at Full HD and while charging, it can heat up so much that Android blocks launching Google Maps on the phone with a message saying it’s too hot to run - though this doesn’t affect Android Auto performance.

You could try disabling Adaptive Connectivity and Wi-Fi scanning on your phone. That should lighten the load on the wireless module and may slightly improve the Wi-Fi link between your phone and the Raspberry Pi.

We dug through the PipeWire and PipeWire-Pulse documentation, and found an environment variable that lets you quickly set the audio latency for specific applications: PULSE_LATENCY_MSEC

Could you please add the following line:
to the $HOME/.hudiy/share/hudiy_startup.sh file, somewhere before the line:
and see how the audio behaves?

You can also experiment with other values, e.g. 30 or 60 (or higher).

This will increase the buffer in pipewire-pulse, which should make playback smoother in case of XRUNs.

Ok I implemented the suggestion above of:
export PULSE_LATENCY_MSEC=90
but I also implemented the suggestion of setting FPS of AndroidAuto to 60 in main_configuration.json as per the release notes for Hudiy 1.2

Horrible stuttering all over the place. Worse than ever.

Changed the FPS setting back to 30 but kept the 90s latency setting and it seems great now. Just without the benefit of 60fps. This was only a short test. This really suggests to me either perforance/efficiency needs to be examined or something to do with the bandwidth available to AndroidAuto. This didn't cause an issue on OAP or on my OpenDash setup so hopefully it can get fixed soon. The usage of AI is fantastic for help with coding but I hope it's not producing too much bloat or inefficiency for the sake of "just getting something working".

Thanks for testing PULSE_LATENCY_MSEC.

We wouldn’t really suspect performance issues in Hudiy itself or in the WiFi module, since those would be easily reproducible on our side. We test Android Auto in 1080p@60 on several Pixel phones (4, 4a 5G, 6 Pro, 7, 7a, and 2XL), and none of them show such problems.

One possible reason that could explain such a performance drop at 60 FPS is that your system might not be using the hardware decoder and it falls back to software one. However, according to the Waveshare Wiki, the display uses v3d-kms, so that shouldn’t be an issue. To rule out potential WiFi problems, the simplest test is to try Android Auto over USB.

Ok will try that next time when I can and let you know