Audio cut-out after a few minutes after boot

[Brownj2]

I am new to Hudiy ( as in the last two weekends of my life have been dedicated to tinkering on this project) ive gone through the ups and downs of new implementation when a non stabdard result is desired... that being said, i am running Hudiy with the following setup

- RPI 4B 2GB Ram
- waveshare 7.9in display
- HDMI 0
- audio jack on display output to AUX input on vehicle (earbuds for bench testing)

The issues im running into are after a few minutes of running the audio will cut and be garbled. There are reminents of the audio file that creep through so i know the pipewire sink is still active. The issue goes away with a simple quit hudiy and relaunch but thats only a fix for a few minutes.

Ive tried to do the prework of understanding pipewire and i saw that there is a quantum buffer that can cause this but when i check the "pactl list sinks" i see that the frequency is already set to the max of ~8000.

I tried to check the .config/pipewire/pipewire-pulse.conf.d/50-hudiy.conf file but i saw that it was blank. Not sure if thats right but thats what loaded after the insall process.

I tried disabling the equalizer to pull that out of the equation but no change.

I tried hard coding the ec_cancel_source variable in the "hudiy-startup.sh" file to the source name of the HDMI 0 port. No change

I tried hard coding the ec_cancel_sink variable to the HDMI 0 sink. I dont know if that works because hudiy launches but android auto doesnt. It does after changing the variable back.

I was worried that during my tinkering of the display and sizing the android auto for the 7.9 display i messed somthing up so i reimaged the whol rapsberry pi but the issue persists.

It is now time for me to ask for help.. any input of knowlege is appreciated!!

[hudiy]

Do you have a microphone input in your setup? If not, as a first step, try not loading the echo-cancel module at all. Based on forum feedback, PipeWire's echo-cancel module can cause various strange issues (especially on Trixie) when it's loaded but there is no actual microphone input in the system. In this thread, you can find an example $HOME/.hudiy/share/hudiy_startup.sh script that does not load the echo-cancel module and uses a "dummy" microphone instead:

viewtopic.php?p=792#p792

[Brownj2]

When i match the suggested .sh config for a dummy mic the launch gets locked up on the pulsing "hudiy" splashscreen. I dont see any traffic in the log files

[hudiy]

Could you please attach the modified hudiy_startup.sh to this thread (zip it and add it as an attachment)? It looks like an issue with the script itself. Also, try running the dos2unix $HOME/.hudiy/share/hudiy_startup.sh command. Some text editors add different line endings, which can cause problems when bash tries to execute the script.

[Brownj2]

I tried the dos2unix command but that didn't solve the issue. attached is a zip file containing the following

- Original : what was on the machine when imaged (works but has audio garble)
- Dummy : proposed dummy mic solution (wont get past pulsing hudiy splash)
- No_Dummy : second config in the proposed dummy mic thread (wont get past pulsing hudiy splash)


I appreciate the help! i'm learning quite a bit through this troubleshooting!!

[hudiy]

Could you please provide the output of $HOME/.hudiy/share/hudiy_run.sh command? Please run it in the Raspberry Pi OS terminal. Splash application has 5 minutes timeout but you can close it via pkill splash or by ALT+F4 shortcut (or switch the window using ALT+TAB).

[Brownj2]

Attached is a .txt file of the full terminal output after running "HOME$/.hudiy/share/hudiy_run.sh"

[Brownj2]

My fault i should also include the output when i run the terminal output that boots but has intermittent garbled audio

[hudiy]

Thank you for providing the output. Unfortunately, the first output file is empty, which suggests that the entire hudiy_startup.sh script is not starting.

What caught our attention in Startup_sh_files.7z is the lack of executable permissions for hudiy_startup_dummy.sh and hudiy_startup_no_dummy.sh. Are you using these scripts? If so, you need to grant them executable permissions (e.g., by running chmod +x hudiy_startup_dummy.sh command). Without executable permissions, Linux will not run any script or program.

[Brownj2]

Ahh foiled by simplicity. Making the dummy file executable worked!

Thank you for all the support and for making this in the firstplace!

On to my next venture of integrating a bluetooth ELM327 module! Wish me luck i have already been brushing up in the forums on otherr common issues!