hudiy.eu

So I drove to work today using HUDIY and it worked great.

One issue I faced with my old open auto pro was cracking/ popping of the audio. The same issue is occurring again.

OAP used pulse audio, and there was an edit to the config file that added the tsched tag to give the audio stream higher priority which fixed it. I haven't messed with pipe wire very much yet, and I only barely know what I'm doing, so I'm wondering if there is already a known fix, and if it's similar to the pulse audio fix.

I looked through the readme but didn't see anything related to it. Any help is greatly appreciated.

tsched likely refers to the timer-based scheduling method. The PipeWire documentation mentions a parameter called api.alsa.disable-tsched at https://docs.pipewire.org/page_man_pipe ... ops_7.html

Disable timer-based scheduling, and use IRQ for scheduling instead. The "Pro Audio" profile will usually enable this setting, if it is expected it works on the hardware.

It can be set via WirePlumber (the session manager for PipeWire) in the file located at /usr/share/wireplumber/main.lua.d/50-alsa-config.lua.
A safer approach is to copy this file to $HOME/.config/wireplumber/main.lua.d/50-alsa-config.lua and make your edits there.

You can also check the PipeWire GitLab - a similar issue related to your audio hardware may have already been reported there https://gitlab.freedesktop.org/pipewire ... /-/issues/.

In this issue for example, the PipeWire author suggests to modify api.alsa.headroom https://gitlab.freedesktop.org/pipewire ... ssues/1569.

Could you please let us know exactly what audio hardware you're using?
We might be able to dig into the PipeWire configuration and find something helpful.

hudiy wrote: Could you please let us know exactly what audio hardware you're using?
We might be able to dig into the PipeWire configuration and find something helpful.

Thank you for the reply. I plan on tackling this after work later.

I have a sabrent USB DAC. Exactly like this one:
https://a.co/d/aSFFJOy

Ok I worked on this tonight finally.

I added a few props to the /50-alsa-config.lua trying stuff out, but this one did the most:
api.alsa.disable-tsched = true

I also edited these props:
api.alsa.headroom = 1024
api.alsa.period-size = 128

I also experimented with the sampling rate and I'm currently set to 44100

It is much improved, but I still get frequent popping and it is a total vibe killer.

The only thing I noticed that was strange was my phone was added twice to the bluetooth manager with only one active connection. I tried to remove the 'ghost' phone but it gave me an error (I did not jot it down unfortunately). Could this be causing an issue somehow?


Ultimately I'm thinking about removing pipewire and switching back to pulseaudio in order to get everything functional again and working perfectly.

If tweaking those parameters improves the situation, then it’s definitely related to the timing of that sound card or the isochronous transfers in its chip.

You could try enabling implicit_fb in the snd_usb_audio driver and see if that makes a difference.

implicit_fb

Apply the generic implicit feedback sync mode. When this is set and the playback stream sync mode is ASYNC, the driver tries to tie an adjacent ASYNC capture stream as the implicit feedback source.

https://docs.kernel.org/sound/alsa-configuration.html

It can be enabled for example by:
Then after reboot you can confirm it is active by:
You can also test the lowlatency option the same way (disable/enable it).

I'm still fighting this.

Have been adding/tweaking props in:
/usr/share/wireplumber/main.lua.d/50-alsa-config.lua

I've tried a bunch of settings for:
headroom, period size, audio rate, allowed rate, clock quantum, tsched, and I'm sure some combinations I'm forgetting.

The popping/crackling is still there. I've seen improvement but it never goes away.

The thread quoted in the first response here, the op of that thread never actually fixed the problem, just minimized it. This doesn't make me very hopeful.

Open Auto pro had the same issue but with a single correction to a config file to add tsched fixed it.

I'm beginning to think removing pipewire and trying to use pulse audio may be a better solution. I've spent quite a few hours on this without much real progress over the initial improvement.

PipeWire is widely regarded in the Linux community as a clearly better and more modern solution than PulseAudio.

If you decide to switch to PulseAudio, you’ll need to additionally configure echo cancellation and the hands-free profile. The equalizer built into Hudiy is tailored for PipeWire and will not work with PulseAudio.

If possible, you can try a different sound card. We primarily use https://eu.ugreen.com/collections/sound ... io-adapter.

Also it may be a good idea to create an issue on PipeWire Gitlab https://gitlab.freedesktop.org/pipewire ... /-/issues/.

This might not be an issue with PipeWire itself but rather with the Raspberry Pi kernel or the driver. Could you send the output of the lsusb command so we can see how this sound card is being detected?

Edit: We found this sound card on our local market. It should be delivered still this week and we will test it.

hudiy wrote: Tue Aug 26, 2025 5:05 pm PipeWire is widely regarded in the Linux community as a clearly better and more modern solution than PulseAudio.

If you decide to switch to PulseAudio, you’ll need to additionally configure echo cancellation and the hands-free profile. The equalizer built into Hudiy is tailored for PipeWire and will not work with PulseAudio.

If possible, you can try a different sound card. We primarily use https://eu.ugreen.com/collections/sound ... io-adapter.

Also it may be a good idea to create an issue on PipeWire Gitlab https://gitlab.freedesktop.org/pipewire ... /-/issues/.

This might not be an issue with PipeWire itself but rather with the Raspberry Pi kernel or the driver. Could you send the output of the lsusb command so we can see how this sound card is being detected?

Edit: We found this sound card on our local market. It should be delivered still this week and we will test it.

Begrudgingly, I'll keep plugging away at pipewire. I'm sure it's just a configuration problem, but my competency is barely passable so this is a tough task for me.

I have tried the UGreen soundcard in the past with OAP, and had issues with the microphone working. I'm sure it boiled down to config, but never could figure it out so I returned it and then purchased a Sabrent usb soundcard instead.

Tonight, I tried using a SoundBlaster Play! 3 USB DAC. Changed the samplerate to 96000 across the board, as well as tweaked a few other settings. Still crackling.

I have several USB hubs on my setup in order to allow extra connections/ peripherals. To rule out them causing the timing/scheduling issues, I moved the SoundBlaster 3 to the Rpi4 USB 3.0 port directly (a royal PITA to do) and I'm still getting crackling.

On the bookworm desktop, I selected "Analog Stereo output, and digital input" in the drop-down menu. I noticed a change, but still can pick out the crackling. I need to go through the gamut of changes in the config file to try and find the goldilocks configuration that will fix the issue.

To repeat the issue, it is most obvious during quieter moments in songs, such as intros or softer acoustic parts. It is difficult to hear when there are a lot of loud instruments/ more energetic sections to music. But it is very easy to hear and I'm concerned it'll damage my speakers if I turn the music up too loud (I have a completely re-done audio system in my car).

Something I've randomly thought of: do I need to have a USB dongle in the Rpi4 in order for HUDiy to work?

The same model of the card has already been sent to us and should be delivered later this week. We’ll try to reproduce the issue. Could you record and send us a short video showing exactly what we should be looking for? You can post it here on the forum or send it via private message.

Which USB dongle are you referring to exactly? If you mean Bluetooth, we’ve tested Hudiy with both the built-in Bluetooth modules on the Pi4 and Pi5, as well as with several USB 4.0 modules like:

https://botland.store/usb-bluetooth-ada ... 08691.html
https://botland.store/usb-bluetooth-ada ... 03712.html

Understood, and thank you for all the help you've been providing!

I should clarify my hardware (I'm listing everything):

Raspberry pi 4
Waveshare 9.3" screen
CarPiHat
USB Bluetooth 5.0 dongle
USB DAC (was Sabrent, now using SoundBlaster play 3)
USB hub X2 (one for extension, one for extra ports)
Pi engineering xkeys HD15 (for button controls)
Logitech k830 keyboard dongle

Should I remove the Bluetooth 5.0 dongle? This was a required component for open auto pro, so I just left it in. My phone always connects to "raspberrypi#1" or something similar to that.

On my drive this morning, the crackling is still present. I will take a video later today and drop the YouTube link.